Right now, you have to pass the routerDelegate, routeInformationProvider, routeInformationParser, and backButtonDispatcher separately to MaterialApp.router, which makes for some awkward code for third-party routing packages that want to provide these and creates unnecessary boilerplate:

final MyThirdPartyRouter myThirdPartyRouter = MyThirdPartyRouter(...);
return MaterialApp.router(
  routerDelegate: myThirdPartyRouter.delegate,
  routeInformationProvider: myThirdPartyRouter.informationProvider,
  routeInformationParser: myThirdPartyRouter.infromationParser,
  backButtonDispatcher: myThirdPartyRouter.backButtonDispatcher,
);

To improve on this, we could define a RouterConfig mixin (or interface):

mixin RouterConfig { // or "abstract class"
  RouterDelegate get delegate;
  RouterInformationParser get informationParser;
  RouterInformationProvider get informationProvider;
  RouterBackButtonDispatcher get backButtonDispatcher;
  // TODO: figure out which of these are optional and need to be nullable.
}

Third-party router packages could implement that interface:

class MyThirdPartyRouter with RouterConfig {
 // ...
}

And MaterialApp.router could then take a single RouterConfig object for some much cleaner code:

return MaterialApp.router(
  routerConfig: MyThirdPartyRouter(...);
);

This could be added to MaterialApp.router in a backwards-compatible way by keeping the existing config options and adding the routerConfig argument as an alternative. We'd have to decide whether we want to disallow using the old API when a routerConfig is provided or whether we want to query the routerConfig first and - if it doesn't provide the requested value - fall back to the values from the old API.