[static-extensions] Use the same kind of erasure with the `on` type as dot shorthands?

[eernstg]

The dot shorthand feature relies on the declaration denoted by a type schema to find a declaration even in the case where the context type is a union type (FutureOr or ?). For example:

import 'dart:async';

class A {
  static A get fresh => A();
}

void main() {
  FutureOr<A?>? a = .fresh;
}

This issue is a proposal that we should use the same rule with static extensions when we determine whether a given on type denotes a declaration:

extension E on FutureOr<A?> {
  factory new name() => A(); // OK.
}

void main() {
  A.name(); // OK.
}

The motivation would be that a developer may wish to introduce some extension members on, say, C?, and they also want to include some constructors of C in the same extension (e.g., in order to avoid having to mention two names in show or hide clauses). Also, the alignment with dot shorthands would make this kind of erasure unsurprising for many developers.

[lrhn]

There is no need to allow an extension on FutureOr<Foo>to declare static members on Foo. You can just declare an extension directly on Foo. More direct to read.

You definitely shouldn't be allowed to access static members on the type FutureOr<Foo>, so it's misleading to appear to declare them on that type.

We have another rule for accessing static members from a general type: static member access through a type alias.

I'd prefer to use the same rule here:

extension FooX<T1,...Tn> on TargetType<...> {...}

can introduce static members on a type declaration T iff

typed FooX<T1..,Tn> = TargetType<...>;

allows accessing statics of T as FooX.staticMember.

Nothing more.

The rule for dot-shorthands is more permissive because we have a context type, and we know the static we access should create something of that type. It's intended for enums and constructors.
Static method in general are not like that.