Reconsider the semantics of type aliases in protocol extensions

By the way, the example here from a 'bug' @Jens shared is another troublesome situation type aliases cause being allowed in protocols: [SR-7217] Protocol composition with conflicting typealiases does not diagnose · Issue #49765 · apple/swift · GitHub

For convenience:

struct Foo {}
struct Bar {}

protocol P1 { typealias T = Foo }
protocol P2 { typealias T = Bar }

typealias P3 = P1 & P2
print(P3.T.self) // => Bar()

typealias P4 = P2 & P1
print(P4.T.self) // => Bar()

You're kind of supposed to not be able to use T on a protocol metatype like any requirement, but you can because it's an implementation, not a requirement. How should this be fixed? Personally, I have no idea how to fix this without doing a workaround or introducing further contradiction.