Also worth remembering:
In order for library users to take advantage of this using protocols they import from a dependency, changes are needed at the declaration site. That means, initially, some protocols will support this feature (probably Apple's ones), and no other protocols will work. That's likely to be very confusing for users, and it will require a transition period before users can just take that support for granted.
What's more, they're then going to report those failures as bugs to the library authors, who are going to be pressured to duplicate their protocols behind #if swift guards because these declarations are incompatible with all prior versions of Swift:
#if swift(>=5.7)
public protocol MyProtocol<Thing> {
// ...
// some long protocol, including all of its:
// - other associated types
// - requirements
// - documentation for those associated types and requirements
// ...
}
#else
public protocol MyProtocol {
associatedtype Thing
// ...
// some long protocol, including all of its:
// - other associated types
// - requirements
// - documentation for those associated types and requirements
// ...
}
#endif
So it's going to look like that, multiplied by every protocol in your library. Also, because it needs to be specified at the definition site, this isn't really just sugar -- this is the new way you're going to have to write every protocol from now on, because users are going to expect this syntax to work.
On the other hand, something which is purely use-site sugar (like MyProtocol<.Thing: Numeric>) would work with all protocols on day one. No transition period. No code duplication for library authors. It has a number of other benefits as well (such as a much smoother migration once you reach the limits of the sugar and need full generics syntax), but I want to focus on the above points.