Previously mentioned were MySQL string columns being allowed to have
different encodings. Which actually sounds like a useful feature in
our polygot, long time if ever before everyone uses Unicode for
everything.
In some domains, like the Web, UTF-8 is essentially all there is; some 94% of al pages. Within the enterprise it can be another story.
However, there's additional complexity here, whether the encoding is specified per-column, per-table, or per-database. Schemes have one of three strategies for implementing strings internally:
The fixed or Chibi strategy, where the internal encoding of strings is specified by the implementation. Chibi itself uses UTF-8 and provides a low-level bytes-in-strings API, but that's not essential. I guess this is the most common strategy, but I don't really know.
The explicit or Gauche strategy, where each Scheme string is labeled with its encoding.
The implicit or Chicken strategy, where strings are basically specially marked bytevectors, and you have to use a higher-level library if you want anything but a single-byte encoding to work correctly.