> Yes, and if we write #u8("bla" #x80 "blubb"), there is no confusion.

+1. Confusion avoided + re-using existing number syntax = win.

I agree that a #u8(...) which can mix single-byte and multi-byte parts
is not as nice and symmetrical as Scheme's (list ...) and (vector ...)
and (string ...) all of which take only single elements as arguments.
However, I also agree with Marc that it's useful and ambiguous. I don't
have a clear opinion on which consideration is more important.

> But there would be confusion if #u8("bla\x80;blubb") meant something
> different than (string->utf8 "bla\x80;blubb")

Would be solved by forbidding \x escapes inside bytestring literals.

> (note the C/C++ also uses the u8 prefix for UTF-8 encoded strings).

That's a nice precedent to have. However, Scheme uses u8 for bytevectors
in general, so the precedent is not as obvious in Scheme.

> And it would forbid Schemes to extend "..." to any string literal that
> is already allowed in that Scheme.

IMHO this restriction is actively desirable. String escapes are
complicated and confusing enough as they are, and any given escape would
be less useful inside a bytestring than a normal string.

> C distinguishes between \Xnn and \Unnnn (since C11) escape sequences.

\U is nice since it's mnemonic for Unicode. \X is confusing since it's
not obvious whether it's a raw byte or a codepoint, and if a codepoint,
which character set and encoding. This confusion is not really anyone's
fault since C (and Scheme) are old enough that they couldn't have
predicted that Unicode became a standard. However, now we have the
benefit of hindsight and should resist the temptation to invent new
escapes that are not mnemonic.