> i do think they made noticeably (and fascinatingly) different choices not only in what they designed for their user interfaces but also what they thought of as a good user interface

Though software written originally for the Xerox Interlisp systems got ported to the MIT Lisp Machine descendants, since the hardware was more capable with more memory. For example Intellicorp KEE (Knowledge Engineering Environment) was ported. It retained much of its original UI (which included extensive graphics features and an interface builder), when running on Symbolics Genera. It looks like one is using an Xerox Interlisp UI when running it on a Symbolics. https://vimeo.com/909417132 For example at 08:30 the screen looks like an Interlisp system, even though it is Symbolics Genera.

Xerox PARC also had real MIT CADRs in their network. I remember seeing a photo, with an office, where the Xerox PARC employee had both an Interlisp workstation and (IIRC) a Symbolics. There is also a video for the IJCAI 81 (International Joint Conference on Artificial Intelligence), with demos of an Interlisp system and a MIT Lisp Machine, both demos recorded at Xerox PARC.

this video is fantastic, thank you! i hadn't seen it before, only the ijcai demo

    https://github.com/lisper/cpus-caddr #Lisp machine #gateware for the
    MIT CADR in modern #Verilog. “Boots and runs.” By #lisper (Brad
    Parker)

It doesn't boot or work -- there are CDC issue and other stuff, plus not working on anything that is easilly found (help wanted to get that stuff working again!). Current version of the FPGA CADR is at https://tumbleweed.nu/r/uhdl -- and CADR restoration and stuff work at https://tumbleweed.nu/lm-3 .

    one quibble: i don't think flavors was around until quite a bit
    later, maybe 01979, so the lispm software wasn't oo until quite
    late. weinreb and moon's aim-602 on it wasn't until 01980 [...]

I wouldn't call it "quite late" -- it was only a 2-3 year gap from the system booting to very heavy usage (1977 - 1979); the Lisp Machine (specifically the MIT and LMI branches) survived for 10 more years after that.

Message passing was added on or around 03/09/79, and things got quickly adjusted and flushed after that.

    MMCM@MIT-AI 03/09/79 21:26:00
    To: (BUG LISPM) at MIT-AI
      Band 6 on CADR1 is a new experimental world load.
    In addition to quite a few accumulated changes, this load
    has some important changes to the message passing stuff.
      CLASS-CLASS now has three instance variables where formerly
    it had two.  Most importantly, instead of the SELECT-METHOD
    being in the function cell of the xxx-CLASS symbol (typically) there is now a
    gensym (called the CLASS-METHOD-SYMBOL) created for each instance
    of CLASS-CLASS which holds the select-method.  The CLASS-METHOD-SYMBOL
    for a given class can be obtained by sending the class a :CLASS-METHOD-SYMBOL
    message.
      A forthcomming essay will describe the motovation for doing this,
    etc.  For the present, I note some incompatibilities and changes to
    operating procedure which this makes necessary.
     Incompatibilites: 
      (1)  The <-AS macro has been changed, and any file which uses it
         must be recompiled.  If this is not done, the symptom will usually
         be  a xxx-CLASS undefined function error.  
      (2)  Any other file which uses DEFMETHOD should eventually be recompiled.
         There is a "bridge" which causes old files to win for the time being,
         but this will eventually go away.
    Since new QFASL files wont work in old loads, its probably a good
    idea to rename your old QFASL files if you compile with the new load.
    
      When you do a DEFCLASS, you always get a fresh class with no methods
    defined.  If you are redefining a class this means two things:
      instances of the old class will continue to work
         (this was not always true before.  However, we still have the
         problem that method names can conflict between new and old versions
         of the class).
      all the methods used by a class need to be reloaded for new instances of the
         new class to win completely.  Also subclasses of the given class
         need to be reloaded.
    
      Since reloading is a gross pain, you should not redo DEFCLASSes
     unless you really mean it.  Probably DEFCLASSes should be put in a
     separate file so the rest of the file can be reprocessed without
     redoing the DEFCLASS.  Hopefully,
     there will eventually exist system features to make this more convenient.

thank you very much for the correction!

01979 is still a lot later than smalltalk-72 or the original cadr design from 01974 (https://www.researchgate.net/publication/221213025_A_LISP_ma... says 'several suitable [semiconductor memory] devices are strongly rumored to be slated for fourth quarter 74 announcement' so maybe they didn't actually get it working until 01975 when they ported emacs to it)

Where does the DEFCLASS stuff originally come from? Is it documented somewhere? As I understand it is from before Flavors? Flavors then replaced it or is there some deeper relationship?

It comes from Smalltalk. Flavors are probobly older than DEFCLASS, ZWEI and the Window system was already using Flavors heavily before DEFCLASS became part of the main system.

Neither Flavors or DEFCLASS got replaced -- they have different purposes though can often be replaced either way.