Or one could more simply reinforce the notion scheme's character type is
simply distinct from (although likely a subset of) the definition of a
new character type targeted to support more generalized text processing
than is minimally necessary to support the definition and processing of
the scheme language itself (which is all that scheme's character type is
specified/suited to be sufficient for).

Where it seems more than reasonable to propose the adoption of the
basic 16-bit unicode character set definition (minus eszett interpretation),
as the basis for a more generalized character type, which would greatly
improve upon the current situation, without suffering from the potential
complexities associated with anything fancier with little marginal benefit.
Where independently it seems like it wouldn't hurt to tighten up scheme's
native character set type and supporting procedure semantics a little as
well.

(with respect to how does C get at scheme's or unicode character string
elements; it seem that although potentially somewhat less optimal at
times, they should be accessed through index and/or iterator functions,
for the same reasons argued to provide implementation flexibility, and
protect C programmers from their potential idiosyncrasies.)

-paul-