Thank you for pointing this out - I think this is a good observation. I completely agree that evolving a generic signature from the sugared form to the more expressive form is important, and this will become a crucial part of the learning curve for concepts like type parameters and associated types.
The need to transform a signature when adding associated type requirements is an inherent problem introduced by the opaque parameters feature that was just accepted. I don't think that's a bad thing - from my teaching experience, showing novice programmers a "desugaring" transformation is a very illuminating part of the learning curve, because it shows that this seemingly-complicated thing they have to approach now is something they've already been writing in their code and have internalized what it means. To me, the implication here is that this desugaring transformation should be surfaced to the user, and it must be discoverable. My opinion is this should be surfaced through a diagnostic fix-it, and I'm also a big fan of this sort of transformation via the refactoring engine, as Gwendal suggested, in both directions (sugared → desugared, and desugared → sugared when possible).
Further, I think this proposal introduces that cliff at exactly the right point. You can start writing the extremely common constraints using this syntax. I do believe that when you're working with wrapper or container protocols like Collection, the constraint you want to write the vast majority of the time is on the Element type, and most conformances to such protocols are generic over that same associated type, which is why I believe the concept of a "primary" associated type is valuable. This proposal allows expressing same-type, conformance (and layout), and supertype constraints on primary associated types, so all of the fundamental constraint types are covered. The first is the core part of the proposal, and the others fall out of structural opaque types. So, Collection<Int> expresses a same-type constraint, Collection<some Numeric> expresses a conformance constraint (albeit with an extra type parameter, but that only makes a difference for those who care about extra type parameters in their ABI), and Collection<some MyClass> expresses a supertype constraint.
When the programmer wants to constrain a different associated type, that's when they really need to learn more about associated types and how they are different from type parameters. For basic constraints, that difference doesn't really matter, because you can constrain both forms of type parameters in the same way.