Not sure we need this in the default app.

I'm not sure either, because sure: it's quite simple to add it when needed.

But since there are already some questions surrounding the new way routes work, this addition might help make it more clear where to put routes for another middleware group.

I agree with @prullenbak that this would make it a lot more obvious where to put routes in other middleware groups.

However, I wonder if apiroutes.php is the best name, because in that case surely routes.php should be named webroutes.php for consistency.

One alternative would be to create a new Routes directory that contains a routes file for each group, and out of the box it contains just api.php and web.php:

app/
  Http/
    Routes/
      api.php
      web.php

Thanks @philbates35, because of your comment I spotted a mistake. It should be routes-api.php, but I made a mistake in the service provider. Will fix that. However, maybe your idea is even better :)

One alternative would be to create a new Routes directory that contains a routes file for each group, and out of the box it contains just api.php and web.php:

It's clear that everyone has their own way of doing things.

For that reason, this is unnecessary.

The current example routes file gives new-comers a flavour of how they can get stuff working, and more experienced users probably already have their own preference on how they want to setup their routing.

One way that I do things is like this: https://github.com/CachetHQ/Cachet/tree/master/app/Http/Routes, https://github.com/CachetHQ/Cachet/blob/master/app/Foundation/Providers/RouteServiceProvider.php#L68.

I will, however re-open this, as the decision ultimately lies with Taylor.

I understand that this can be done in multiple ways, but that's the case with everythting in Laravel.
Also, of course there's a line you have to draw (you can't add groups for all thinkable routes). But at the moment, the web group is the default and nowhere is it clear how to add api-routes, which were right there in the routes file before.

I think this is a change that should be discussed on the develop branch. I will note that Spark does indeed do this exact thing (with the exception of the file being called api.php).