re: Does a MOP user really know the names of the slot where initforms and
    initfunctions are stored?

No.


CLOS:SLOT-DEFINITION-INITFORM is the documented way to access the :initform
information . . . (but I forget whether there is a standard requirement that 
it be SETF'able too;) so I just used the same code as Heiko first sent out, 
perturbed as little as possible, to show that under guidance of AMOP, we are 
very close to some de facto standards.

CLOS:SLOT-DEFINITION-INITFORM is setf'able in all of Harlequin's Lisps.  In
LCL, CLOS:SLOT-DEFINITION-INITFUNCTION is also setf'able.

re: Should one not change the slot-initform by calling
    reinitialize-instance on the class with appropriate canonicalized
    slot-definitions, that changes
    (f :accessor f :initform "tail") to
    (f :accessor f :initform "headtail")

It should be possible to utilize CLOS:COMPUTE-EFFECTIVE-SLOT-DEFINITION
to change the way that slots "inherit" various features.  The alternative
to the "patch up" trick of Heiko's code is much more complex---in effect
one would have to duplicate the inheritance for all the SLOT-DEFINITION
slots and then make the new instance of the EFFECTIVE-SLOT-DEFINITION.
In metaobject programming, I myself have frequently done the trick of 
patching up the result of a CALL-NEXT-METHOD


I'm not sure why the updator functions for "derived" metaobjects (e.g., like
effective-slot-definition, as opposed to direct-slot-definition) are not
specified to exist; for some of them it may not make sense, I suppose.



-- JonL --