This was my main thought when reading the proposal. It's somewhat unsatisfying to have LazyMapCollection, LazyFilterCollection and LazyCompactMapCollection, when they could all theoretically be implemented using LazyCompactMapCollection and a suitable _transform. Or perhaps they could all be folded into LazyCollection, which isn't very useful on its own, by giving it an appropriate closure instance variable.
These options might be unacceptable for performance reasons (or source compatibility reasons?) but it would be nice if this was mentioned in the proposal, or clarified in this review thread. I suppose this could all become more of an implementation detail if Swift had generalised existentials, but currently all of these types are exposed to users in ways that can be verbose or confusing.
Edit: Looking into it, the discussion thread has some more detail on this that unfortunately didn't make it into the proposal. e.g.
This is a good point that you could only work around by e.g. storing a Boolean instance variable that keeps track of whether filter or similar had ever been called on the Lazy*Collection. So perhaps the answer is performance reasons. There is some benchmarking of various options in that thread, but it is quite hard for me to understand and summarise. The part about performance testing at the end of the proposal is a link to a fairly significant amount of code with no summary of results.