I have a number of initial questions, comments, and opinions to make.
(I sent a similar email a few days ago, but there were problems with my
SRFI mailing list subscription, so it wasn't received yet; I hope the
editors see this email first so they can not bother to send the other
one.)

First, my thoughts on the matter of syntactic details.  With respect to
compatibility with SRFI 9, I think it would just be easier if the
predicate were mandatory.  I don't see much of a reason to omit it,
and, by mandating it, it removes ambiguity: it clearly delimits the
type name & the constructor specifier from the fields.  Also, I don't
like the token for specifying mutability.  I think it would be better
to have a <field spec> nonterminal where the token for mutability is
_not_ a symbol; I think it would also be a bit more consistent to allow
a mutable field with an accessor but no separate modifier defined.
This replacement <field spec> nonterminal would fix both problems,
given some <mutability token>, e.g. #T/#F:

  <field spec> ->
      (<field label> [<accessor name>] [<mutability token>])
    | (<field label> <accessor name> <modifier name>)

The last syntactic detail that bothers me is the use of record types'
constructors in the pattern matching.  It would seem more sensical to
me to use the record type names themselves, not their constructors;
this would also solve the problem that required identifier macros --
which I am loathe to consider -- when defining the constructors so that
they could be used as regular variable bindings, bound to procedures,
as the specification specifies: they would no longer need syntactic
information used in pattern matching.

I also have a somewhat deeper semantic question: can SRFI 57 be used to
define subtypes of record types defined with SRFI 9?  My suggestion: an
emphatic *YES*.

I am also *vehemently* opposed to the completely unrestricted operator
of reflection RECORD->SEXP.  Reflection should either be completely
expurgated -- as I'd prefer --, or, if you intend to include any at all
in this SRFI, highly controlled by whomever defined the record type.
For example, Scheme48 has a simple, controlled mechanism for disclosing
the components of particular record types, though mostly for printing
unreadable objects.  I don't want to clutter this email describing it,
however, unless requested; request if you want me to.

A smaller issue that I brought up on c.l.s seemed to have been left
unnoticed: record type equivalence seems to be based on name, not on
identity of the record type.  I believe this could be fixed by defining
an extra variable when invoking DEFINE-RECORD for a token identifying
the newly defined record type, and comparing against this, instead of
symbolic names, in BUILD-MAKER.

Regarding implementations, it is obviously not tractable for many
Scheme implementations to implement DEFINE-RECORD as a syntax-rules
macro of such extreme proportions; although I find it amazing that you
wrote such a macro, I don't think it's practical, _especially_ not for
implementations that implement syntax-rules by translating the
expression into Scheme, compiling the Scheme, and then running that --
for _every_ use of syntax-rules.  I believe it would be a good idea to
provide an alternative implementation of DEFINE-RECORD in terms of even
a non-standard macro system, such as the fairly widely implemented
explicit renaming.*  It would also be undoubtedly easier to maintain as
the SRFI evolves than this gargantuan set of syntax-rules macros.

Finally, it would also be good if an implementation were provided -- be
it in syntax-rules or explicit renaming or anything, as long as it can
be shown that it works -- that based records on the low-level record
interface used internally by SRFI 9's implementation, because that is
what most 'real' implementations will likely be based on.

While I'm writing this, too, I may as well cast a vote for specifying
pattern matching in a separate SRFI, presumably one that simply shares
its reference implementation.