This might not be a huge proposal, but imho the topic itself is - I think even two reviews aren't enough to discuss all implications. I'm not saying we need more review cycles, though: Imho this is a perfect candidate for SE-0264 (review #2) — Standard Library Preview Package...
I agree with @bzamayo that it's odd to talk about ranges all the time, while the real code is actually focused on single indices. Take Collection.range(at:) as an example - this could as well have an additional length parameter, which imho would also make it significantly more useful in other contexts besides this proposal.
Another interesting example is public func ranges(of element: Element) -> RangeSet<Index>.
The natural result of this operation is a set of indexes, and using ranges here looks like an (possible) optimization which leaks out.
On the other hand, there is a very similar functionality which naturally produces ranges, and which I consider to be a big gap in Swift:
We have Apple Developer Documentation, but that's only part of NSString, not String.
Therefor, I'm puzzled that something like public func ranges<C: Collection>(of subsequence: C) -> RangeSet<Index> isn't even mentioned as a possible next step.
In the long run, I even see some overlap with [Prototype] Protocol-powered generic trimming, searching, splitting,, but I no idea how well the two concepts could work together.
My bottom line:
Improving the ease of use of collections is a crucial topic, and I really doubt that old procedure with small, simple steps will produce great results. Instead, I'd prefer a preview package with a complete vision of how to work with Collection - or even several competing approaches, so that we can compare the pros and cons.