Hi Alexander,

Your defmacro-enhance system assumes that ALEXANDRIA:FLATTEN will return all symbols inside of a backquoted form.
The assumption stems from a similar assumption in Doug Hoyte's implementation on which your code seems to be based.

But a possible change to the SBCL Lisp reader would render the assumption incorrect, and your system in need of repair.
Consider the code fragment from your AIF macro example:
  `(LET ((,E!-IT ,TEST)) (IF ,E!-IT ,THEN ,ELSE)

It would be legal for READ to return this expression as:
  (QUASIQUOTE (LET ((#S(COMMA :EXPR E!-IT) #S(COMMA :EXPR TEST)))
    (IF #S(COMMA :EXPR E!-IT)  #S(COMMA :EXPR THEN) #S(COMMA :EXPR ELSE))))

in which our proposed QUASIQUOTE is an ordinary macro whose expansion is, in this case:
  (LIST 'LET (LIST (LIST E!-IT TEST)) (LIST 'IF E!-IT THEN ELSE))

Freedom to implement the character macro #\` thusly is quite explicit in CLHS:

2.4.6 Backquote
An implementation is free to interpret a backquoted form F1 as any form F2 that, when evaluated,
will produce a result that is the same under equal as the result implied by the above definition,
2.4.6.1 Notes about Backquote
Since the exact manner in which the Lisp reader will parse an expression involving the backquote
reader macro is not specified, an implementation is free to choose any representation that preserves
the semantics described.
Often an implementation will choose a representation that facilitates pretty printing of the expression,

Indeed the structured comma facilitates pretty-printing, more so than the approach which CLHS gently suggests modeled on the Scheme language.
The point being, until QUASIQUOTE gets macroexpanded, the s-expression you're processing is not a tree of conses and symbols, and FLATTEN will return to you the #S(COMMA) atoms which your GREP-SPEC-SYMS code does not understand, instead of returning the symbols inside them.

In addition, naive code-walking (so far as FLATTEN can be called code-walking) invariably gets the use/mention distinction wrong, which is a separate issue, but worth thinking about.  For example in my macro below, E!-BAZ is accidentally considered as a symbol that is referenced when in fact it is a symbol used only as a quoted object.
DEFMACRO! introduces a spurious binding of that symbol into its body, and a helpful compiler like in SBCL will warn about it:

(DEFMACRO! FOO (BAR) `(LET ((,G!-BAR ,BAR)) (MUMF ,G!-BAR 'E!-BAZ)))
; in: DEFMACRO! FOO
;     (LET ((DEFMACRO-ENHANCE::E!-BAZ (INTERN "BAZ")))
;       `(LET ((,DEFMACRO-ENHANCE::G!-BAR ,DEFMACRO-ENHANCE::BAR))
;          (DEFMACRO-ENHANCE::MUMF ,DEFMACRO-ENHANCE::G!-BAR
;           'DEFMACRO-ENHANCE::E!-BAZ)))
; caught STYLE-WARNING:
;   The variable E!-BAZ is defined but never used.
; compilation unit finished
;   caught 1 STYLE-WARNING condition

I can suggest two things:
(1) After SBCL changes its backquote internals, write an SBCL-specific function that is it still basically blind to proper program structure, but will at least understand QUASIQUOTEd COMMA objects.
(2) Use a real walker to grovel out symbols correctly, fixing both problems mentioned above

The first will be simpler, but untestable until you've gotten a hold of the new backquote implementation, which isn't committed yet, never mind released.
(Though it should be apparent you'll just need a COMMA-P predicate and COMMA-EXPR accessor from an internal package)
The second will be harder, but not too much, and is surely backward compatible, and will fix the bug about spuriously detected symbols.

Please let me know if this is all clear.
Thanks
Doug