The current draft of SRFI 237 is insofar feature-complete as
everything is expressible with the syntactic form of
define-record-type that is defined in the spec.

However, because of the scope of this SRFI, the syntactic form comes
in two versions, one based on SRFI 9 and one based on R6RS.  The
complete feature set is only accessible through the R6RS form, where
it is obvious how to extend it with new features syntactically.

At least two members of the community, Daphne and John, have voiced
their wish to bring the SRFI 9-part on par (except for the implicit
introduction of identifiers the R6RS form can do).  While not
technically necessary and while it has the danger of manifesting the
coexistence of two forms, I have agreed to amend the SRFI 9-version to
improve acceptance of this SRFI.

A few ideas have been exchanged about how such an extension of the
SRFI 9-form of define-record-type could look like.  John suggested
having an augmented plist in place of the record name, like in

(define-record-type (colored-pair parent pare nongenerative #t)
  (make-colored-pair ...)
  colored-pair?
  ...)

The yet unsolved problem I see with this proposal is how to naturally
incorporate non-default protocols (in the sense of the R6RS record
facility) into the syntax.  With the existing SRFI 9 syntax, the
constructor subform "(make-colored-pair ...)" is an exact template for
a later constructor call.  For example, one would like to retain this.
In the SRFI 9 form, the formal arguments refer to field names, but it
is unclear how to make any such relation still meaningful in the
presence of non-default protocols.  Finally, we don't want any
extension of the SRFI 9 syntax to be mistaken for a SRFI 99/SRFI
136/SRFI 150 syntax unless its meaning coincides.

I have written this long post because I would like to appeal to the
community (or at least that part that would prefer a SRFI 9-like
syntax) to help me come up with convincing solutions.  I don't want to
add something half-baked into the final version of this SRFI because
this would be of no use to those who want to stick to the SRFI 9
syntax.

Semantically, both syntactical versions of the define-record-form have
to be compatible, of course, as everything else would be against the
spirit of the reconciliation mentioned in this SRFI's title.

Thanks for reading,

Marc