I think (if I understand correctly) that I worked through a similar concern, that having no explicit names makes it hard to express constraints that cross nesting levels:
// naive matrix of Int: fine in this syntax
func foo(arg: some Collection<.Element == some Collection<.Element == Int>>>){...}
// naive matrix whose row-index type matches its column-index type: how?
func foo(arg: some Collection<.Element == some Collection<.Index == ??>>>){...}
// If I understand correctly the ..Element is straw-man syntax to fill the ??
I eventually realised that at least in this context I can name the index type independently:
func foo<Ind>(arg: some Collection<.Index == Ind, .Element == some Collection<.Index == Ind>>>){...}
The concern of course is not that code like that up there would be common or encouraged, but that the pitch seems intended to make it safe to have contexts in the language in which names cannot be added: then expressibility of even weirdo edge cases becomes interesting. Sadly I don't follow the details of opaque types and generalized existentials well enough to understand whether this strategy can always be applied, or whether there might be contexts (opaque return types perhaps?) in which there's no place to hang the generic parameter.
Jumping threads here, but this feels like more appropriate place.
So the new syntax discussed here feels to me like it should be thought as part of overall discussion to design anonymous types.
Some types probably are not applicable, but for example thinking about anonymous structs, those are tuples, in a way. So to add functionality you might do
I'm not sure I see the analogy. Tuples are not anonymous in the same sense as I'm talking about, since you can refer to them structurally. If we were going to support shape-generic programming over structs, I think we would do so in terms of things that look like protocols, and could fit in the existing constraint model.