[This actually a MOP compliance issue.]
One of the use cases of the CLOS Metaobject Protocol is to be able to add
one's own :allocation kinds. The book "The Art of the Metaobject Protocol"
describes the addition of hash-table-based slots as an example, and the
CLOS MOP specification has wording that suggests that the kinds
of :allocation is not restricted to the set supported by CLOS by default
(i.e., :instance and :clos). See the specification of ALLOCATE-INSTANCE in
the CLOS MOP specification that talks about slots with allocation :instance
on the one hand and slots "with any other allocation" on the other hand.
I have attached a test case in which a hash-table-based slot access is
implemented. The relevant part is that the method compute-effective-
slot-definition accepts the :allocation :hash in this example. (Since
subclasses of hash-class could add further allocation kinds, this class
doesn't do any further checks here.)
When run.lisp is loaded, which executes the test case, CLisp (erroneously)
complains that the :allocation kinds for the slots defined in the example is
:hash, and not :instance or :class. This code works in current versions of
CMUCL, OpenMCL and SBCL.