I'm not sure what I think about this revision. I'm finding it a bit tiring to keep coming back to find a new revised proposal under review, which I then need to read through from beginning to end and consider freshly (no, looking at diffs is not enough to assess the integrity of the overall proposal), so I haven't done it for this revision yet. I think it would be much more efficient if each of the sub-threads I started in the last review contained some discussion of the specific points raised and a message describing whether—and if so, how—the author intends to address those points. Then we could have a discussion of the trade-offs and hopefully reach some consensus on the direction before going through a whole 'nother review cycle. That's why I went to the trouble to break up the posts the way I did.
So this isn't a review, and I doubt I'll have time to do a complete one during the review period. That said, I can address one of the prominent changes I see here. Let me first refer to my definition of “subrange”: a range of (consecutive) elements in a collection (probably I should have said a “sequence” (lowercase s) rather than a “range” just to avoid confusion).
This usage is not consistent with that definition:
let indicesOfEvens = numbers.subranges(where: { $0.isMultiple(of: 2) })
The method would have to return something like a collection of slices to be consistent with the definition. Now, my definition of “subranges” isn't necessarily gospel, and maybe someone else can come up with a definition that makes everything consistent again, but this also points to another problem that seems to be persisting, so I'll ask again:
What is this thing the latter method is returning, semantically?
If its primary semantic role is as a collection of index ranges or slices, then it should conform to collection and not have top-level set APIs, and something like the proposed naming direction makes sense. If its primary semantic role will be to act as a set of indices, then the proposed naming direction makes no sense to me.
In fact, you see this semantic clash in action in this example:
let rangeOfEvens = numbers.moveSubranges(indicesOfEvens, to: numbers.startIndex)
Here we clearly have a set of indices being used as an input. The neither the author nor the reader of this code care about the representation of that set as a sorted collection of ranges.