> If I see
>   #,(f32 1.0 2.0 3.0)
> in a program all I know is that the value will be the result returned
> by applying some arbitrary function to `(1.0 2.0 3.0).  This doesn't
> tell me very much about what the program means.

Still, as you said you do know that #,(f32 1.0 2.0 3.0) stands for a
value produced by a constructor that is associated with a tag f32. It
is this understanding that is the major thrust of SRFI-10. To learn
what the tag f32 actually means and what kind of value the constructor
produces, one has to consult a third-party registry. The situation is
very similar to SRFI-0:

<blockquote cite="SRFI-0#Rationale">
Features are identified by feature identifiers. In order for the
semantics of this construct to be well-defined, the feature identifier
must of course refer to a feature which has a well-defined
meaning. There is thus a need for a registry, independent of this
SRFI, to keep track of the formal specification associated with each
valid feature-identifier. The SRFI registry is used for this
purpose. It is expected that features will eventually be assigned
meaningful names (aliases) by the SRFI editors to make reading and
writing code less tedious than when using "srfi-N" feature
identifiers.
</blockquote>

For instance, consider an Example from SRFI-0:
	(cond-expand
	 (command-line
	  (define (program-name) (car (argv)))))

Notation (argv) tells us that argv is bound to a procedure or a
syntax rule. What exactly it returns (in particular, whether the
program name is the part of the result, and whether this name is the
absolute path to an executable) is unknown. One has to locate and
consult the corresponding SRFI.

Now consider
        (cond-expand
         ((and srfi-4 srfi-10 srfi-10-4)
          (define sample-vector '#,(f32 1.0 2.0 3.0))))
The situation is the same: one has to consult SRFIs to figure out
the meaning of the expression.

Finally, let's compare

	#,(f32 1.0 2.0 3.0)
with
	#f32(1.0 2.0 3.0)
as per SRFI-4. Without any further information, both expressions are
obscure. However, if SRFI-10 is in effect, the first expression can be
"parsed" as a read-time application. The second expression cannot be
parsed at all without reading a specific SRFI. Suppose somebody will
introduce a new kind of a uniform vector -- of signed 128-bit
integers. Without SRFI-10, he probably has to specify an external
representation of these vectors as #s128(1 2 3), thus asking a
conformant system to extend its reader to handle yet another
hashsign-xxx notation. With SRFI-10, one can introduce external forms
#,(s128 1 2 3) or even #,(s128vector 1 2 3). One does not need to
extend the reader or fight for the remaining letters that may be
specified after the hashsign.

	I will add a clarification about define-reader-ctor being
merely a recommendation. Thank you for the suggestion. I will wait a
couple of days to batch the updates, so to speak.