> My thoughts exactly. Allowing any non-ASCII character is liable to cause confusion at best and actively mislead at worst as to what bytes are actually in the bytevector, even if a standardized encoding were chosen.

Strongly agreed.

Even if we stay in the Latin-* (i.e. ISO-8859-*) range, different
Unicode normalization forms will encode some of those characters
differently. One would have to inspect the byte-level encoding of the
Scheme source file from which a particular literal is read in order to
figure out the bytes. A source file can also be re-encoded from say
Latin-1 to UTF-8 which would again change the byte-level encoding while
the display in a text editor keeps looking identical.

I'd expect string bytevectors to mostly be useful for protocol and file
format implementations and the like (i.e. much of the same applications
that SRFI 175 (ASCII character library) is useful for). It's rare for
those to have non-ASCII magic strings.

> In addition, John Cowan is considering a `bytevector` procedure which will add exactly this functionality. I’m discussing with him whether to merge our two SRFIs (his is not submitted yet) or keep them separate.

(bytevector 1 2 3) is a standard procedure in R6RS and R7RS. Is John
planning a convenience procedure with the same name that is more lenient
about the types of arguments it can handle?