That's certainly part of my motivation here. A design that always attaches a name to the opaque/erased thing could work too, but I think there's some benefit to a notation that reduces the amount of names a user has to think about. As they say, naming things is one of the hardest problems in computer science, and names impose a cognitive overhead on the reader to keep track of what the names represent. Notation that reduces names can reduce cognitive load; this is why we like programming languages with expression syntax instead of writing assembly language or LLVM IR, and why it's simpler to write foo(_: P) than foo<T: P>(_: T).
It seems to me that, with the proposed syntax, you should be able to express almost anything you would be able to express with where clauses, with a few open questions. As @anandabits noted, there are a few possible answers for where the <> ought to go in a protocol composition when relating associated types from different protocols. Also, if we did introduce multiple opaque types in a declaration, you would need to introduce extra generic parameters to be able to relate associated types across the opaque types, e.g. to say that two opaque arguments and their return type all return collections with the same Element, you'd write:
func concatenate<Element>(a: some Collection<.Element == Element>,
b: some Collection<.Element == Element>)
-> some Collection<.Element == Element>
instead of directly same-type-constraining the three .Element associated types.