Ok. Now, you said that you're doing this partly to improve clarity.
The problem this has is that it's no longer visually apparent which
arguments go into the parent constructor and which one into this
type's. (And this is exactly the kind of thing I can never remember.)

It has occurred to me that a simple FIELD-VALUES macro could
translate into the VALUES expression of my suggestion, so you can write:
(define-type eq-hash-table
(constructor (lambda (pred hasher size)
(field-values (parent-arguments pred
hasher
size)
(child-fields 0))))
(fields (gc-count mutable)))
Would this help satisfy your concern regarding clarity?

One could, if one wanted to, go further by making FIELD-VALUES abstract (i.e.,
keeping the number and order of the return values of FIELD-VALUES abstract).
This would allow extensions such as the following, which overrides the parent
constructor (which I notice the draft does not seem to allow):