Thanks for an interesting srfi.   I prefer xml-style, for (1)
starting with # makes it stand out more as an extended syntax,
and (2) for something like srfi-109 we can refer to the existing
XML standard when it's useful (e.g. entity reference).

There's one thing that confused me, though.
(Maybe because of the arrangement of the document).

The document appears to propose a new literal syntax, for
it mentions adding new literals for new types and then
goes on to compare it to srfi-10.  However, what follows
is not a syntax of literals, but a new reader syntax
of a list, with a certain assumed format and function.
(Well, it's quasi-literal, so it is not exactly about literals,
nevertheless I found the flow of discussion a bit confusing.)

The difference between literals and proposed quasi-literals
is mostly visible when they appear within literals.  Srfi-10
works for those cases:

  '(1 2 #,(URL "http://example.com"))  => list of 1, 2 and URL object

  (case x
    ((#,(char-code #\a) #,(char-code #\b)) (do-a-or-b x))
    ...)

   ;; Suppose #,(char-code #\a) reads as the ascii code value
   ;; of #\a.

I assume srfi-108 can't be used for these contexts.

Srfi-10 can also be used as an external representation of
objects of user-defined datatypes, since if you define an
appropriate writer, you can make those objects written out
and then read back to get the object of the same type/attributes.
I assume srfi-108 doesn't work like that---if you write an
object in srfi-108 syntax and then read it back, you'll get
a list ($quasi-value$ ...), not the object of the written type.

The "Readtable literals" section kind of opens the door for
implementations to make srfi-108 work like true literals, but
if that's the purpose, it needs more explanations.  For
example, the resulting value of $quasi-value$ must be self-evaluating
object, otherwise the following expression will behave differently
whether the syntax is converted to objects at read-time or not.

   (list #&myobj[xyz])

To allow read-time object construction, it might also be better
to mention that the value of quasi-liteal without unquoting
shouldn't be affected by the dynamic environment---it must yield
the same value whenever the quasi-literal is evaluated (it also
consistency in whether the value is constructed at macro-expansion
time or at evaluation time.)

I felt that it may be easier to mention at first that srfi-108
is really about a shorthand notation of an S-expression for
calling a constructor.   It can compare to literal syntax
like srfi-10, but it would also be nice to refer to the
difference between quasi-literals and literals.