Repository: flutter
Issue: Material App is complicated/confusing
Labels: framework,f: routes,customer: crowd,c: proposal,P2,team-design,triaged-design

### Use case

`MaterialApp` wraps the tree in a navigator/router (transitively via `WidgetsApp`). Since there are so many different approaches to navigation now (Nav 1, Nav 2, GoRouter, Nav 1 router based, etc) this massively balloons `MaterialApp`'s constructor. Not to mention, `MaterialApp` breaks Nav 2 on Android ([system back closes the entire app](https://github.com/flutter/flutter/issues/140674)) and requires a [workaround](https://github.com/flutter/flutter/issues/66349#issuecomment-696788657) to use.

Here is a list of navigation related constructor arguments in `MaterialApp`:

1.  `navigatorKey`
2. `home` - this would probably just be replaced by `child` if nav logic were removed
3. `initialRoute`
4. `onGenerateRoute`
5. `onGenerateInitialRoutes`
6. `onNavigationNotification`
7. `navigatorObservers`

Then there's the entire `MaterialApp.router` alternate constructor.

Many of these args have non-obvious runtime constraints too:
https://github.com/flutter/flutter/blob/3df4e735d5d0bd2db7930098eba1b3e620d77aa0/packages/flutter/lib/src/material/app.dart#L199

And, since most of these arguments are just proxies for `WidgetApps`/`Router`/`Navigator`, they're a maintenance burden to keep in sync, have unreadable inline docs (may depend on IDE settings), and their logic is hard to trace when clicking through the source code:
![image](https://github.com/flutter/flutter/assets/10675231/4fa73682-e349-433c-80a2-e1d40011e898)


### Proposal

Handling navigation logic in `MaterialApp` made sense when Flutter's navigation options were simple and limited. We are well past that point.

Here are a couple proposals of various levels of disruption that would resolve this problem. Note that all of these proposals probably involve modifying `WidgetsApp` to mirror the `MaterialApp` changes
1. Allow the developer to provide a navigator key corresponding to their own navigator, `MaterialApp` will bind the system back gesture to the navigator associated with that key, and provide no other navigation logic of its own. Pros: no disruption, minimal boilerplate. Cons: `MaterialApp` becomes more complicated instead of less, would be hard to disambiguate this new arg from the existing `navigatorKey` arg.
2. Alternate constructor that has no navigation based args, developer is responsible for putting a navigator in the tree and binding the system back gesture to it. Pros: no disruption, no subtle behavior. Cons: `MaterialApp` remains complicated, developer has to write a fair amount of boilerplate to opt out of material app nav.
3. Remove all navigation related logic from `MaterialApp`. Pros: simplifies dramatically. Cons: high disruption, newbies who would've been happy with basic default behavior now have to write a lot of boilerplate (`PopHandler`, `Navigator`).

3 feels very "pure" but is quite disruptive. 1 feels a little sloppy/awkward. 2 feels like the sweet spot as it both avoids disruption while providing an elegant escape hatch.

Happy to hear your all's thoughts and am more than willing to write the associated PR(s) myself to make any of these 3 happen.