> there only seem to be "shoulds" and not "musts" in the specification.

Not so: the grammar extensions and reader behavior are a must.

> Your examples show that the Schemes in existence don't follow SRFI
> 243's recommendations.  For example, something like XXX#YYY is not the
> written representation of a datum.  Moreover, if you type "<" instead
> of "+" in the Chez Scheme REPL, you see that the angle brackets are
> not usually paired.

In standard Common Lisp, angle brackets are not universally paired
either. They are only paired in #<...> syntax.

In Scheme, <...> are conventionally paired in the names of types,
particularly record types and OOP classes.

SRFI 243 doesn't ascribe any meaning to "<" and ">" outside the
particular syntax #<...>.

Only readers who need to skip past #<...> datums actually have to parse
the paired delimiters. Normal readers are free to stop at #< and raise
an error without reading any further.

The sample implementation parses '> symbols, but it is cheating. A
serious reader that skips #<...> would not do that. It would instead use
an equivalent of read-delimited-list in Common Lisp
(http://clhs.lisp.se/Body/f_rd_del.htm). That function reads a proper
list except that the closing bracket is different.

> Adding something like "<...>" to <datum> in the Scheme grammar doesn't
> look like a particularly good idea because, by R7RS, <datums> are what
> the reader successfully parses, and each <datum> must come with a
> mapping to Scheme values.  But SRFI 243 doesn't define corresponding
> values.

That's the whole point of the SRFI.

- A datum is a standalone representation of an object, but not all
objects can be represented standalone.

- You need to be able to (write) those objects somehow, so we write
#<this stands in for something that is too difficult to write>.

Instead of reserving the #<...> syntax you could also make (write) raise
an error. I haven't heard of any Scheme (or Lisp) implementation that
does that. The ability to print _some_ information about an unreadable
object is useful, even if you can't preserve read-write invaraiance.
This is particularly true when #<...> is nested in another object. If
(write) raised an error, the outer object could not be printed at all!
IMHO it's clear that #<...> is the lesser evil.

Instead of #<...> it could be #unreadable(...). But since #<...> is an
extremely widespread part of Lisp and Scheme tradition, I'd prefer to
honor the tradition.

Note that turning #<procedure foo> and #<port bar> into #procedure(foo)
and #port(bar) is not a good idea since the latter notation suggests
that you can read those objects back in.

> What would (foo . #<unreadable>) be for a Scheme reader that
> "skipped" #<...>?

Some such readers would simply ignore all expressions containing
unreadable stuff, as if those are whitespace.

Some such readers would have an "unreadable" pseudo-object-type, and
read the stuff between #<...> into it. Perhaps it would want to wrap an
outer expression containing unreadable sub-objects in a special
container, but probably not.

See Weinholt's "laesare" library for one reader that might want to do
something like this.

You're generally concerned about standard Scheme semantics. In that
case, #< would just be a read error.