I'm trying to implement srfi-150 on Gauche and getting into a compatibility issue with srfi-99, regarding using accessor names to designate fields in the constructor specification.

Srfi-99 is designed in the way that syntactic API can expands into procedural API. You can construct all the necessary procedures from procedural API, and the syntactic API can just bind those values to the designated variables.

Unfortunately, srfi-99 procedural layer do not include information on accessors in rtd. So it is not possible to simply expand srfi-150 syntactic layer to srfi-99 procedural API + simple definitions.

Of course, srfi-150 doesn't need to be fully compatible to srfi-99; we need to extend the procedural layer anyway to allow non-symbol field names. Such extension is trivial if implementation has some sort of first-class identifiers. However, using accessor names to designate fields in constructor spec would record that rtd also need to keep the way to map accessor names to fields, *in addition to* what we have in fieldspecs.

My concern is that if each implementation that chooses to implement srfi-150 on top of procedural layer extends make-rtd in its own way, there will be different extended make-rtd, and it can get in way of creating procedural API srfi compatible to srfi-150 in future.

An ideal solution is to propose extended procedural layer together with this srfi, but that would take time.

Will it be reasonable to include informative section outlines how srfi-99 procedural layer needs to be extended? Just like srfi-99 notes the optional extension on shield, opaque and uid for make-rtd?

I might be able to come up some concrete suggestion as I implement srfi-150 on top of extended srfi-99 procedural layer.