Would this not also fix this?

I think adding a flag to override the inner workings of a widget is not a scalable pattern across the framework, and not very different from the solution above, especially in terms of being discoverable to the user. I haven't been able to find another case of overrideMediaQuery, but this was likened to the Scaffold.extendBody in the linked issue. Maybe just using the same naming convention will make it easier for the user to associate its purpose.

Would this not also fix this?

Did you meant MediaQuery.of(outerContext)? If yes, this is one of the workaround for this issue: storing the parent context, as done in this unit test. The problem is that this workaround is not easily discoverable and relies on a good understanding of BuildContext 😉

I think adding a flag to override the inner workings of a widget is not a scalable pattern across the framework

I agree too. The problem here is that BottomSheet inner workings relies on something that few widget do : consuming padding using a call to MediaQuery.removePadding. Doing so, it breaks the inner SafeArea that a user might want to add (and it is very difficult for the user to find why composition with a SafeArea does not work inside a BottomSheet). I think the Flutter way would have been to let the user use composition to decide if he wants to consume the top padding. Just my 2 cents to explain why this fix is mainly a way to find an official workaround without breaking existing code. Otherwise, users will use workarounds such as this one: adding an inner MaterialApp!.

Adding a property is the good option for compatibility and I agree that the main point is to find a good name for it. I agree too that overridesMediaQuery is not very good and unusual. extentBehingNavigationBar will be on par with Scaffold similar property, but discoverability is not optimal and this name is not fully self explanatory in the BottomSheet case. Naming is hard 😄

I just remembered that showDialog has a useSafeArea property. We might do something similar here. Its default value would be false. If true, instead of adding a MediaQuery that consumes the topPadding, we can insert a SafeArea. It will also make showModalBottomSheet and showDialog similar. And I think it is great for discoverability because most of the users participating in those issues were looking for a way to add a SafeArea in their BottomSheet.

@Piinks I could try to implement this, do you think adding a useSafeArea property is a valuable approach?

Well said! I do appreciate how thorough you always are. :)
I think useSafeArea makes sense so we have a consistent patterns for showModalBottomSheet and showDialog.

Can you try it with the test cases reported in the issue? I think this sounds like a great solution.

@Piinks
I updated the PR according to our previous discussion: adding a useSafeArea parameter to showModalBottomSheet.

About persistent bottom sheets, shown using showBottomSheet or Scaffold.bottomSheet property, despite both implementations adding a BottomSheet instance, the way they insert this widget in the tree is very different. The unusual MediaQuery.removePadding call is only done when calling showModalBottomSheet :

There is one open issue, #69676, related to showBottomSheet and SafeArea. After investigating it, I think it is more actionable to not cover these two different cases in the same PR.

Great! Thanks for investigating!