The "standard" has a huge amount of undefined behavior and also defined unspecified behavior. For example for everything "system class" it is undefined how this

The "standard" has a huge amount of undefined behavior and also defined unspecified behavior. For example for everything "system class" it is undefined how this thing is implemented - there is an API specified. An example is the condition system: it is not required that a condition is a CLOS object. There is also a bunch of things which can be implemented or ignored. It is fully standards conforming to ignore all type declarations. About some central Lisp features, there is nothing in the standard. Garbage Collection is such a thing. The standard does not even mention it, thus it is also not requiring it. It says nothing about invoking a GC or an interface to the GC. It's also not forbidden to define subsets of the standard. For example there were several implementations of CL to C compilers developed, which lack a lot of dynamic behavior at runtime. L is a subset for embedded systems. SubL is a variant used to program Cyc. CLICC was used to compile the applications of the expert system shell Babylon to C. Then there are implementations with large sets of extensions to the standard: streams in CLOS, conditions in CLOS, hash tables with various extensions, various extensions to TRACE and STEP, MOP for CLOS, ... So there is a range from a primitive CL (implementing only the minimum requirements) to a fully CLOS-based CL with lots of extensions. In between are exotic & large implementations like Genera, where parts are written in Flavors, for example there are several dozen PATHNAME (for UNIX, Mac, DOS, VMS, ... pathnames) classes, which are implemented in Flavors and where (pathname ...) has parsers for various filesystems. SBCL devs have also experimented with extensions like extensible sequences.