to hide implementation details, but the way it handles instance payload

bothers me; it seems that the abstraction is broken there in a sense that

it effectively excludes implementations that allocate once for each

instance (e.g. contiguous memory for a type metainformation and payload).

I suppose the current implementation is a balance between API complexity

and abstraction, but I'm afraid that this limits implementations to integrate

srfi-137 into its core, leaving anything built on top of srfi-137 to live in one-layer-off

from native type system (meaning, a record system on top of srfi-137 would

have extra overhead than the native record system).

The alternative is to hand over allocation to the constructor.  Unfortunately,

that makes API more like low-level, imperative style, losing the functional

feeling of the current draft.

  (constructor x ...) => <instance>

     Constructor takes variable number of arguments, allocates instance

     large enough to hold them and initialize instance "slots" with x....

  (accessor <instance> n) => x

     Accessor takes index of the value.

  (modifier <instance> n x) => unspecfied

     Modifier replaces n-th value of instance with x.  Immutability of slots

     should be handled by the layer above this srfi.

The current draft's beauty is that it makes mutability out-of-scope, but

I think it's superficial---not the right abstraction.  You have to deal with it

anyway in some layer, and the current draft doesn't prevent bad code from

breaking abstraction anyway. 

I wish we could have type abstraction purely detached from low-level

storage management, but I can't think of a good way to do it in Scheme

semantics.