Thank you for the post!
After the acceptance of SE-0341, I'm lean to think that the syntax of named generics should share the semantics of some. Let's consider pseudo syntax, <some T>. This is a named version of some syntax, but it can provide necessary and sufficient features.
Generic parameters and opaque result types corresponds as this. Of course where constraints work.
func foo(value: some Numeric) -> some Numeric
// corresponds to
func foo<some T: Numeric, some U: Numeric>(value: T) -> U
// works
func test<some C>() -> (C, C) where C: Collection, C.Index == Int { ... }
Furthermore, when T is shared in both parameter position and result type position, we can understand it as the next.
func square<some T: Numeric>(value: T) -> T { value * value }
// corresponds to
func square<T: Numeric>(value: T) -> T { value * value }
Though very simple, the merit of this <some T> syntax is huge.
First, learners would more easily understand this syntax than generics and addressed 'result type parameter clause', because they are just named versions of some. Second, we can more naturally and fluently write reverse generic result types, and so that it reduces the potential 'cognitive load' which you raised as the problem of 'result type parameter clause'. Finally, we can even replace current syntax of generics with this <some T> syntax.
Currently, 'generic result type' is allowed as badCreatePi. However, this usage of generics is not recommended (as this), and goodCreatePi is better API.
func badCreatePi<T: ExpressibleByFloatLiteral>() -> T { 3.14 }
func goodCreatePi<T: ExpressibleByFloatLiteral>(type: T.Type) -> T { 3.14 }
// corresponds to
func goodCreatePi<some T: ExpressibleByFloatLiteral>(type: T.Type) -> T { 3.14 }
<some T> syntax does not provide stand-alone 'generic result types', and so that they cannot express badCreatePi, while <some T> syntax supports goodCreatePi. As this, we can do all 'good' things with this <some T> syntax.
So, I'd like to suggest named some syntax like <some T> which fully supports generic parameters, opaque result types, and generic result types with the metatype arguments, should replace current syntax of generics.