According to SRFI-10, a <hash-comma-datum> can only appear in the
expansion of a <datum> production. (It can also appear in a <tag>, but
that leads cyclically back to <datum>, so we can ignore it.)

Out of curiosity, I traced the grammar expansion backwards to see
exactly which forms may contain a <hash-comma-datum>.

    <datum> <-- <list>
             |  <vector>
             |  <abbreviation>
             |  <quotation>
             |  <macro use>
             |  <case clause>

The first few forms also lead cyclically back to datum:

    <list>         <-- <compound datum> <-- <datum>
    <vector>       <-- <compound datum> <-- <datum>
    <abbreviation> <-- <list> <-- ... <-- <datum>

The last few trace back to expressions. Therefore, these are the only
contexts in which you can use a <hash-comma-datum>:

    <quotation>   <-- <literal> <-- <expression>
    <macro use>   <-- <expression>
    <case clause> <-- <derived expression> <-- <expression>

For example:

    (quote #,(<tag> ...))
    (<keyword> #,(<tag> ...))
    (case <key> ((#,(<tag> ...)) <sequence>))

The quotation produces a literal. The expansion of the macro use may
compare the <hash-comma-datum> to a datum in the macro pattern, using
EQUAL?. The case expression will compare it to the key using EQV?.

Quasiquotation is notably absent from the above list. I originally
explored the SRFI-10 syntax when trying to figure out what `(#,(foo ,a))
would mean, especially given the reference implementation, which relies
on read-time application.

Is read-time evaluation an important element of SRFI-10? If so, then the
lack of quasiquotation syntax makes sense (but see below). If not, then
the SRFI should probably extend the grammars for <compound datum>,
<quasiquotation>, and maybe even <transformer spec> so that hash-comma
data acts more like list/vector syntax.

Even if SRFI-10 is for read-time literals only, there are still a couple
of weird quirks in the syntax. Since a <qq template 0> is an
<expression>,

    (quasiquote (unquote (quote #,(foo ...))))

is legal, but

    (quasiquote #,(foo ...))

is not. In other words, you can put a hash-comma form in a
quasiquotation, but only if you unquote it and requote it first. Also,
it seems a bit strange that one must quote a hash-comma form in the
first place, since it behaves in most ways like the <self-evaluating>
literals. Therefore, I suggest the following errata:

    <self-evaluating> --> <boolean> | <number>
         | <character> | <string> | <hash-comma-datum>

    <qq template D> --> <simple datum>
                     |  <hash-comma-datum>
                     |  <list qq template D>
                     |  <vector qq template D>
                     |  <unquotation D>

This would permit the use of unquoted and quasiquoted hash-comma data
without eliminating the ability to evaluate them as read-time literals.

The other alternative is to make the hash-comma form completely
analogous to the list/vector form, as I mentioned above. However, that's
a much more complicated change, and it doesn't lend itself well to the
read-time application implementation. It might be better to leave
hash-comma simple and introduce a separate syntax for "generalized
compound data" (in a new SRFI).

On a more whimsical note, SRFI-10 has one other subtle flaw: It's very
easy to mistype #,(...), at least on my keyboard. The rapid succession
of shifted and unshifed characters makes it quite easy to type 3,(...)
and #<(...) and #,9...). If any of you decide to implement the more
ambitious "generalized compound data" SRFI, I strongly recommend that
you use a shifted keystroke for the middle symbol!
--
Bradd W. Szonye
http://www.szonye.com/bradd