This motivation is actually the most exciting part of the proposal from my point of view. Extending your silly example just slightly:
func foo<C: Collection>(_ c: C) -> LazyCollection<ReversedCollection<LazyFilterCollection<LazyMapCollection<C, ()>>>> {
return c.lazy.map{ String(describing: $0) }.filter { Bool.random() }.reversed()
}
Look at that return type! I don't want to have to spell that anywhere. When I'm prototyping in code (and even more often in playgrounds) I often end up wrapping my functional-style map/filter chains in return Array(...) so that this sort of thing can be spelled foo<E: Element>(_ c: [E]) -> [E] instead, even though I'm now losing all of the standard library lazy smarts and all the Collection genericness at all of my internal API boundaries. Maybe once I've got everything prototyped I go back and do it the right way.
So this is a plea to try to make some lightweight version of the proposed syntax work for in-same-resilience-domain APIs where the compiler knows the concrete type already, so the declaration can be spelled something like func foo<C: Collection>(_ c: C) -> opaque Collection {}.