The language is not moving from one syntax to another. We have introduced a very concise syntax that covers a limited -- but extremely common -- subset of generic code for the purpose of progressive disclosure, and this allows you to elide an explicit generic signature completely in those cases. I don't think it's feasible to completely change the syntax for generics and transition all code to a new syntax, especially because I don't think the some Collection C syntax covers all use cases for generics. For example, this syntax does not work for generic types with stored properties that reference type parameters for reasons I laid out in this post, nor does it work for input type parameters in a generic signature that are only used in the result type (which we've determined isn't the best pattern, but it is used in Swift code today). Generic types are especially problematic because a type parameter can be declared in the primary declaration of a generic type and only used in an extension. In general, the some Collection C syntax or any variation of it suffers from the problem of becoming attached to the nearest generic possible generic signature to where the implicit type parameter is declared. If we introduced this new variation of some, we'd have this matrix of use cases that each have a different recommended syntax. I don't think that decreases the complexity of the language or improves learnability at all.
I do agree that the some Collection C syntax reads more like prose, which I personally find very helpful, but I think we're also conflating the goals between this post and the other recent generics proposals. I think this discussion would benefit from an answer to this very good question:
The goal of opaque parameters and the same-type requirement sugar is indeed to improve the learnability of the generics system and provide a stepping stone to more advanced generic code via progressive disclosure. However, the goal of this discussion is to enable the full expressivity of arbitrary constraints on opaque result types and existential types (to the extent that we want arbitrary constraints on existential types), and therefore the intended audience here is much more advanced. I anticipate that the need for this feature will be much more rare than the need for the very concise some Collection<Element>. I completely agree with @xwu that the design here should prioritize expressivity, which likely means sacrificing conciseness in the syntax.