Use case

• material 3 and material 2 coexistence through opt-in approach may be

  • confusing
  • have unwanted side effect (material2 regressions and or technical debt)

  having 2 separate packages would solve that

 return MaterialApp(
    theme: ThemeData(useMaterial3: true),
    // ...
  );

• uses-material-design seems a "non standard" approach compared to other packages
  (even bundled ones like cupertino)

flutter:
  uses-material-design: true

• would make sense if material.io maintained it
  (possibly and eventually, but definitely not happening if it's just bundled in the sdk)

• a strength of flutter is the ease of implementation of "branding", but sometimes if hindered by over reliance on material widgets and it's limited extensibility of it, un-bundling it would/may "force" the package to be more interoperable with flutter's core widgets and their extensions

Proposal

un-bundle (if that's even a word) material from flutter sdk an make it available as package

Notes

I have the feeling that this has been briefly discussed between the lines of some tangentially related issue
(maybe this one?), but I couldn't find a "start to end" discussion about it