> I'd provide all five ci procedures; people will expect them.

I'll add them and make a new draft. Best to get this SRFI in shape ASAP
so we can concentrate on more complex things. It's already almost done.

> Case-sensitive procedures would not provide any special benefits except on
> a system where string comparison order is not Unicode code point order.

OK so it doesn't involve anything fancy like combining adjacent characters.

> (UTF-16 systems have that issue, but I know Kawa works around it to provide
> Unicode order anyway.)

The current draft of the SRFI says: "An implementation whose native
character set is [something other than Unicode or extended ASCII] is
permitted to assign ASCII to some other contiguous range of character
values [than 0..127] so that (ascii-char? (integer->char 0)) is false,
and this SRFI has been designed to work correctly even in that case."

I think insisting on a contiguous ASCII range is a bare minimum
requirement. And if the range is contiguous, then any case-sensitive
comparison preserves order among all ASCII characters. The ordering
between ASCII and non-ASCII characters may change between
implementations, but not within a particular implementation, so it
should be ok.