Comment 1 for bug 1826607

The error is telling you exactly what not to do, which isn't strictly speaking just a CLOS-related issue: don't make a macroexpand hook that invokes the macroexpand hook.

Suppose that instead of your generic function, the macroexpand hook were an interpreted function.
The exact same problem occurs, but it manifests as stack overflow:

(defun f2 (form-car fn form env)
  (cond ((eq form-car 'defun)
         (format t "~&boo~%")))
  (funcall fn form env))

* #'f2
#<SB-KERNEL:INTERPRETED-FUNCTION F2>

* (g)
INFO: Control stack guard page unprotected
Control stack guard page temporarily disabled: proceed with caution

debugger invoked on a SB-KERNEL::CONTROL-STACK-EXHAUSTED in thread
#<THREAD "main thread" RUNNING {10005885B3}>:
  Control stack exhausted (no more space for function call frames).

So to be clear, are you asking for this to "work", or are you asking not to run into CLOS limitation? I'll grant that there are CLOS implementations that do not encounter this problem, but if this is purely a contrived test, it seems like it's doing what it should.

One more thing - I had to cheat to get stack overflow- I remove the test for infinite looping in the interpreted function case, but that test could succumb to the same failure even if I did not - a compiled function that calls an interpreted function would fail.

Maybe the thing to do is prevent recursive use of *macroexpand-hook* in our logic for MACROEXPAND.