existing record systems so that various extensible type system can

be implemented portably on top of it.   It is politically correct in a sense

that it is neutral to existing record systems.

However, existing implementations must already have internal type 

handling mechanisms, and if an implementation already supports some

record type, it's likely that it wants to directly integrate it to the internal

type system.  Such internal type system doesn't need to fit smoothly

with srfi-137 protocol, in which case srfi-137 just adds complexity as

opposed to simplifying it.

It is certainly convenient to have some minimal protocol so that variations

of record types can be experimented out.  But if it's for experiment (and

reference implementation of srfis), it can just choose existing popular

record system.  If the experiment shows such record type is pretty

valuable, implementations will adopt it with the way most natural to the

implementation, skipping "common factor" layer if there's any (*1).  Then,

this srfi would only serve temporarily, in proof-of-concept state.

It may still be useful, but I wonder it's worth to introduce yet another

abstraction.

(*1) With reference implementation using this srfi, there would be

no guarantee that the types created in that system works with

other generic operators supported by the implementation natively.

In practice, if the implementation offers a debugger, for example,

it would be nicer that the new record system also works with it; thus

implementors will want to adopt the new record system through its

native type system, instead of going via the layer provided by this srfi.