I do think it makes sense, that since T is a single type conforming to collection, and associated types can only be bound to a single type per conformance, a reasonable interpretation of something like T: Collection<Numeric> would be "a Collection whose element type conforms to Numeric".
(As opposed to: A collection of existential any Numerics, a type which doesn't even conform to Numeric!)
So I wouldn't blame developers who get confused by this. We can all agree that the generics system needs to be more intuitive, and whilst this shorthand will help abbreviate some constraints, I don't think it will actually make the system simpler or easier to learn.
As soon as you need a subtype constraint (which IMO you should prefer whenever possible), you'll face an even higher wall than you did before, because we so heavily optimised syntax for the other thing (does that sound familiar?). If we had a more balanced approach to constraint shorthands, it would be simpler to see what is happening and why changes have the effect they do.
// Bonus - subtype constraints are even easier than same-type.
func frobnicate(strings: Collection<.Element: StringProtocol>)
func frobnicate(strings: Collection<.Element == StringProtocol>)
It might also be worth considering going the other way - allowing subtype constraints to be used in more places, so people can just write where Element: Int or where Element: String, to allow those constraints to be more easily relaxed to protocol constraints.
It may not work for classes, but at least when the constraint is a value type, we can be relaxed and just DWIM.
// The compiler knows what you mean, can't it just be chill?
func frobnicate(strings: Collection<.Element: String>)