If you just take ANSI CL, then it clearly seems to require that (find-class ’t) is implemented as an instance of a metaclass other than either of the three standard-class, structure-class, or built-in-class, due to the requirement that defclass cannot define any subclass of built-in-class, and due to the statement that (find-class ’t) is a system class, so neither a standard-class nor a structure-class. CLtL2 didn’t have a notion of a system class, but there it was completely unspecified what the metaclass for (find-class ’t) was. METACLASS-OF-SYSTEM-CLASS:UNSPECIFIED can be read as addressing the resulting inconsistency wrt (find-class ’t), among other issues. So according to this reading, AMOP is incorrect to specify that T is a built-in-class. However, I believe the actual specification bug is the requirement that defclass cannot specify subclasses of built-in-class. It should have specified T as an exception to that requirement, or should have stated that it’s only restricting the direct subclass relationship here. Alas, ANSI CL can’t be changed anymore. It is also weird that ANSI CL seems to clearly imply that there is at least a fourth metaclass besides standard-class, structure-class, and built-in-class, without explicitly spelling it out. (Along the way, I found another inconsistency in ANSI CL: The last sentence in 4.3.7 states the following: "A standard class defined with no direct superclasses is guaranteed to be disjoint from all of the classes in the table, except for the class named t.” - referring to table 4.8. However, that table contains standard-object, which is inconsistent with the fact that any standard-class directly or indirectly inherits from standard-object. The corresponding table in CLtL2 didn’t include standard-object. Sigh…) Pascal On 31 Aug 2014, at 00:59, Alastair Bridgewater