"Instances belong to a type that is disjoint from any existing
Scheme type, including types created by other calls to make-type."

Does that mean the sample implementation would be illegal in
implementations where records created by define-record-type
are recognized by the record? predicate of (rnrs records) or
(srfi 99) as belonging to the type consisting of all records?

Scheme has no official notion of type, so "a type that is disjoint
from any existing Scheme type" is meaningless without further
explication.  The sentence quoted above should be replaced by
something along the lines of the following sentence of SRFI 9:
"Records are disjoint from the types listed in Section 4.2 of
R5RS."

As has been mentioned by others already, this SRFI's notion of
subtyping affects only the predicates returned by the make-type
and make-subtype procedures, and bears no relationship to the
Liskov substitution principle.

Marc Nieper-Wißkirchen wrote:

> While they provide unique types, neither SRFI-9 nor R7RS-small
> records provide subtypes.

SRFI 137 doesn't provide subtypes either.  It just uses the
word "subtype" in a misleading way.

> More sophisticated record systems like SRFI 131 or SRFI 136
> provide subtypes. When the underlying implementations differ,
> however, it may not be possible to intertwine, say, SRFI 131,
> SRFI 136, and (rnrs records) in inheritance chains of subtypes.

The reason it is not possible to create chains of record subtypes
that include record types defined by both SRFI 131 and SRFI 136
is simple: SRFI 131 matches field names by name as though they
were symbols, while SRFI 136 uses positional matching.  That
incompatibility cannot be removed by cleverness of implementation,
and that incompatibility is not ameliorated by SRFI 137.  Adding
yet another incompatible notion of subtypes does not improve the
situation.

We have prior art in which inheritance chains of record subtypes
can mix record types defined using (srfi 9), (rnrs records),
(srfi 99), (srfi 131), and (scheme base).  The only problem with
that is a recent claim that records defined by (scheme base) are
not intended to be compatible with record systems in which field
names are symbols.  Implementations can ameliorate that problem
(without resolving it for portable code) by ignoring that recent
claim.

WG2 has the power to resolve that situation or to make it worse.
We'll see.

> If all implementations of record-type systems agree on using
> SRFI 137 for creating and subtyping types, they will at least
> be compatible in this regard.

That is not going to happen.  I suppose WG2 could mandate that
for R7RS (large), but it would be hard to sell that mandate
during the ratification process.  Even if ratified, the primary
effect of that mandate would be to discourage implementations
from implementing R7RS (large).

SRFI 137 adds another dimension of inheritance incompatibility.
Implementations can resolve that new problem by simply ignoring
SRFI 137, or by implementing SRFI 137 without making even the
slightest effort to create any interoperability between the
useful notion of subtyping provided by (rnrs records), (srfi 99),
and (srfi 131) and the cockeyed notion of subtyping introduced
by SRFI 137.

Will