Here are a few remarks that can be found in patch.lisp.  They give a
sense of some issues that were addressed by the implementation.  This
is by no means an exhaustive list of what needed to be dealt with, but
it gives a flavor at least.

.....

Changed chk-stobj-field-descriptor to allow stobj fields.

Disallow state as a stobj array field.

Initialization: :initially must be nil; use creator calls for unique stobjs

Disallow state as a stobj field.

For initialization in logical definitions, use (non-exec (creator)) rather
than (creator).

In raw Lisp initialization of an array of stobjs, call the stobj creator
once for each index rather than putting the same initial stobj at every
index.

Resizing needs to fill in extra slots with distinct creator calls.

A comment explains that updater is called because of *1* function.

We lay down code asserting that there are no duplicates among the actuals,
except when we can easily figure this out in advance (because all indices
for a given array field are numbers or quoted numbers).

Avoid trans-eval under stobj-let bindings, to avoid confusion about
references to "local" or global stobjs (as explained in a long comment).

Declare producers that are bound stobj vars to be ignored, which is safe
because of the check-vars-not-free around the consumer.

Among the many legality checks for stobj-let is one that checks that we
have a concrete stobj, not an abstract stobj (otherwise, "fields" doesn't
even make sense).

I needed to allow a stobj recognizer to be applied to an ordinary object.
(I forget why at the moment, but it would be clear if I run my tests
without this surrounding trans-or!)

[Already mentioned above, actually:]
We need to disallow the use of ev etc. for stobj-let, because the latching
mechanism assumes that all stobjs are global, i.e., in the user-stobj-alist.

We translate the stobj-let in pieces, since we disallow ordinary
translation of stobj accessors and updaters for stobj fields, in order to
avoid aliasing problems.