> it seems to me that STRING<? and
> others are better left for trivial tasks like sorting strings of digits;

Very few such trivial tasks exist in the application domain.

> for example, if you want to implement string sets as
> sorted lists, it's much better to use fast ordering predicate,

I argue that this is the only time that a language-insensitive ordering
predicate is useful: implementing ADTs on top of strings.  And for that,
the character-ordering predicates remain.  (Indeed, the character-ordering
predicates,
much like the character-wise casemapping procedures, seem useful for little
else.)

> especially because collation is actually a complex process
> involving generation of "collation keys" which can be reused:

Agreed.  But for single-pass cases where you don't want to cache and reuse
sort keys, I would like the string preds to do the right thing, which, I
claim,
is language-sensitive collation.

So it's back to the string procs vs text procs thread of a couple of months
ago.

> the other hand, some Schemes have already implemented
> extended versions of these predicates accepting more than
> two arguments to make them similar to < and others

I see.  Might foul the (APPLY STRING<? some-set-of-strings) case
if it had to check the type of its last argument.

I also want (WITH-LANGUAGE ...) to solve the Turkish casemapping issue.
Separate point.