A few from top of my head:
- Internal type system might have used symbols or identifiers that services "type name"---e.g.
for debugging or introspection. srfi-137's type payload can be any Scheme values, so either
such internal system adds new field in its type structure to hold the type payload, or modify
internal system to accept any object as a type name. It's doable, but its extra complexity
without clear benefit (except supporting srfi-137 itself).
- Records can be implemented in a way that an instance is stored in a single contiguous
memory, with type tag and instance payload together. In such systems, the constructor
and accessor are likely to need copying and extra bookkeeping; or it implements srfi-137
based instances with extra layer (i.e. internally srfi-137 instance is represented as a
native record with a slot that holds given instance payload), which is probably the case
if srfi-137 is implemented on top of existing record systems such as srfi-9. Then we get
seemingly unnecessary layering---any record system based on srfi-137 will have a
structure that "a record system based on srfi-137 layer that is emulated by the native
record system". Probably this layering is the thing bothering me.
Do existing record systems so fragmented that they'll hinder further development? I might
be unaware of that since usually I stick to a single implementation. For example, it's
easy for Gauche to provide srfi-137 on top of existing type system. But if there will be
nice record system srfi, I'd prefer implementing it directly bypassing srfi-137 layer.
Then it doesn't matter if the initial srfi is based on srfi-9 or srfi-99 or whichever existing
record system.