I’m not sure I understand this perspective. That’s exactly how associated types have always worked in all supported circumstances? That is, conforming types declare a type or type alias with the same name and it becomes the associated type (rather than shadowing it). Protocols that refine other protocols declare associated types with the same name to add constraints. This design is simply being extended to parameterization of the original protocol itself.
I’d argue, actually, that adding new syntax to the language not used elsewhere decreases consistency rather than increases it, while increasing the learning curve rather than decreasing it.
For the author, enforcing an extra annotation doesn’t prevent error but adds another reason why code might not compile—it offloads to the human a requirement to match up two declarations which the compiler does not even require for disambiguation, where mismatches are vastly more likely to be an oversight in bookkeeping than to reflect an unintentionally included parameterization. Such a design would also rather significantly increase the number of mechanical changes required to support prior versions of Swift.
As to the reader, I don’t see any intrinsic reason why the sigil
primary would cause someone who would otherwise think that there are two declarations with the same name to think otherwise. Nothing about “primary” means “it’s the same thing as what’s in the angle brackets.”