Sergei Egorov has suggested that SRFI-9 be less specific.  He would
like the following three issues to be left to the implementation:

- Whether record-type definitions with the same name are disjoint.

- Allow internal record-type definitions without specifying whether
  they are generative or not.

- Whether SET!-ing any of the bindings introduced by a record-type
  definition has any effect on any other bindings.

The problem with this approach is that any program that makes use
of something explicitly unspecified is not portable.  R5RS is
already rife with unspecified behavior (does DEFINE introduce a
binding, order of argument evaluation, CHAR->INTEGER encoding,
inexact numbers, and so forth).  People are bitten by these all
the time.  Code that runs perfectly in N implementations fails in
the N+1st.

The SRFI mechanism provides a good alternative.  SRFI-9 gives a
minimal specification.  SRFI-X can be identical, except that
it allows internal record-type definitions that are generative,
while SRFI-Y allows them and makes them non-generative.  The
majority of programs probably will not use internal record-type
definitions and can run in implementations that provide SRFI-9,
-X, or -Y.  Programs that do use them can require SRFI-X or -Y,
making it clear which semantics is needed for that particular
program.

Another issue Egorov raises is the interaction between genericity
and program debugging.  To my mind this is a metalinguistic area
in which implementators are free to do whatever they like.
Reloading a program or part of a program may create new record
types or it may reuse the old ones.  The SRFI deals with the
semantics of programs, not with how they are run or debugged.

                                         -Richard Kelsey