Ah, ok, I started understanding the trade-off. Let me reiterate,
though this has been obvious to those who understood the issue from the beginning...
(1) We want an efficient way to specify character position in a string. (cursor).
(2) In some implementations it can be as lightweight as fixnum.
(3) Because of 2, we can't simply extend srfi-13 to take cursors as start/end arguments.
(4) So either we need to duplicate most of srfi-13 procedures as string-something/cursor,
or to introduce a new abstraction (span) that embeds a range in a string and duplicate
most of srfi-13 procedures as span-something.
(5) The latter can also eliminate optional argument handling.
If I have to choose from the above options in (4),
I'd still prefer having more procedures on a same kind of objects (string-something/cursor)
rather than having another kind of objects (span) with mostly the same set of procedures.
But fundamentally, I feel both ways are net loss; any addition of string operations
would require addition of their counterpart (or the consistency would somewhat be lost);
it includes any future string-related srfi, and any implementation-specific string operation
extensions.
I'll ponder this more.