Do we have a plan on the criteria that justify a @awaitNotRequired? It feels like marking parameters optional, and it might be better off reviewed on a case-by-case basis, even better split into separate PRs based on categories of reasons.

Do we have a plan on the criteria that justify a @awaitNotRequired?

There is a lint (unawaited_futures) turned off in the Flutter SDK which basically flags Future-returning function call sites without the await keyword. Is there a scenario where a method flagged by this lint should not have the @awaitNotRequired annotation?

Thanks for the review @dkwingsmt. I didn't think there are situations in the framework where some Future-returning methods do not have a preceding await but should. This is a valid point and makes sense to me.

Is this review exhaustive? i.e are the methods you've pointed out the only ones that should have await added instead of the annotation? Asking because I want to go ahead and open PRs to add await to the ones you have pointed out.

I didn't review the ones under dev since I'm not as familiar. I went through the other files, although I'm not as confident on some cases such as Navigator. In general my recommendation is that this tag should be used with caution since it's basically ignore-lint that applies to all users.

Related: #182233
In this issue, an error slipped through all try-catch efforts and caused app crash. This was caused by the following structure:

void A() {
  assert(false); // Exception thrown
}

Future<void> animateTo() async {
  A();
}

void handleEvent() { // Sync handler
  animateTo();  // The future is not awaited.
}

void D() {
  try {
    handleEvent(); // D thought this was enough catching.
  } catch {
    FlutterError.report(...);
  }
}

This shows the risk of allowing futures to not be awaited: Async errors will not be caught at all.

Therefore I think we should not allow futures to be un-awaited (except maybe in tests, with discretion). All futures should either be awaited or have a .catch.

This PR is affected by code freeze. I've suggested Victor to split this PR into two parts, landing the non-material/cupertino part while holding the remaining until the freeze is lifted.

I moved the code-freezed changes to a separate PR. So this can be merged cleanly.