Oh, yes indeed, I didn't mean to add such extensions to this SRFI.
They would be for a future SRFI (possibly replacing SRFI 196) when
(and if) it is ready.
And I think I made a mistake in my previous post. A procedure
"range-map" would be possible, wouldn't it? The mapping procedure
would just have to be post-composed with the indexer, wouldn't it? If
that's the case, I would propose to add this one (and this time before
finalization).

Two more things:

- The algorithmic complexity of the indexer procedure is not taking
into account. For example, the true algorithmic complexity of
"range-start" will most likely depend on the running time of the
indexer procedure. Of course, as with comparators, one can simply
factor our the algorithmic complexity of the indexer procedure, but
this will make the given running time bounds somewhat arbitrary
because the indexer procedure is not under the control of the user but
can be changed by subrange or range-reverse. Depending on whether
comparators will be changed as well, the same argument applies to
ignoring the complexity of the comparator.

- range-split-at has rounding problems for numeric ranges, hasn't it?
In fact, it seems to assume the following more general constraint on
indexers:

(indexer lower-bound (+ k l)) is equal to (indexer (indexer lower-bound k) l)

As one sees from the example of numeric ranges, we don't want to
guarantee such a constraint. So range-split-at has to use a custom
indexer for the second subrange. As this has to be changed anyway, I
would drop the last-minute addition of this constraint (for l = 0)
again as it is obviously unnatural (which the general case shows).

Marc