In programming language theory, subtyping (also subtype
    polymorphism or inclusion polymorphism) is a form of type
    polymorphism in which a subtype is a datatype that is related
    to another datatype (the supertype) by some notion of
    substitutability, meaning that program elements, typically
    subroutines or functions, written to operate on elements of
    the supertype can also operate on elements of the subtype.
    If S is a subtype of T, the subtyping relation is often
    written S <: T, to mean that any term of type S can be safely
    used in a context where a term of type T is expected. The
    precise semantics of subtyping crucially depends on the
    particulars of what "safely used in a context where" means
    in a given programming language.

With SRFI 137, there are hardly any contexts in which arbitrary
values of the subtype can safely be used where values of the
supertype are expected.

Yes, it is certainly the responsibility of the programmer to fill this with meaning (e.g. to make the class of the above mentioned contexts non empty).

On the other hand, also SRFI 99/SRFI 131/SRFI 136 do not guarantee much with respect to subtypes. They only guarantee that the subtype can be a substitute of the type when it comes to the accessor and mutator functions of the type.

> I don't see the value of "prior art" by itself if it is incompatible to the
> current version of R7RS-small (as seen by some, without the erratum that
> field names are symbols).

Although R7RS (small) is the most recent quasi-standard, it may
not be the last, and there are earlier quasi-standards whose
value is attested by the number of libraries and programs that
rely upon them.  As of this writing, I very much doubt whether
the volume of code that relies upon R7RS define-record-type
exceeds the volume of code that relies upon SRFI 9, R6RS records,
or SRFI 99.  I am quite certain that the volume of code that
depends upon interpretations of R7RS define-record-type that
are incompatible with the field names as symbols semantics is
far smaller than the volume of code that relies upon prior art.

That's a point. But do you think that there is much SRFI 9 code out there (if any) that would break if field names weren't symbols but identifiers? It would only make a difference if the record definition is being expanded by a macro use and then only in the unlikely case that two field names have the same underlying name as a symbol but not as an identifier. (Unlikely because Alex's use cases aren't relevant for code that does not expect field names to be identifiers.)

Marc