CLISP, CCL, and ABCL all print 10; 9; 10 for this code fragment.
SBCL's full-eval agrees with that, however compiled code prints 10; 3; 10.

* (defun foo () (symbol-value 'a))
* (let ((a 3))
   (declare (special a))
   ((lambda (&aux (a 9)    ; Does this bind A specially?
                  (b (foo))
                  (a (1+ a))) 
     (declare (special a))
     (values a b (symbol-value 'a)))))

The first &aux variable (or equivalently a LET* binding) treats the questioned line as special binding in agreeing evaluations, however ir1tran specifically says:
"... LET* bindings may be duplicated, and declarations always apply to the last."

I can see that being a defensible position for a TYPE declaration, since at worst it fails to restrict the type of a shadowed prior binding of the same name. But this only works if you start by first associating each bound decl to its referent, choosing exactly one referent - for 0 referents would be a free decl - using the aforementioned disambiguation rule.
That a pretty strange thing in the case of SPECIAL because it makes it hard for code walkers to understand the principle involved - that there must not be a later possible referent.

I would argue in favor of the evaluator's behavior, and printing a style-warning in the compiler.
The evaluator uses the intuitively obvious approach: given a list of things that are supposed to be special and a list of things to bind, if a binding's symbol is in the list of specials (also of course considering the globally pervasive specialness if relevant), then the binding is special.

A search on comp.lang.lisp turned up KMP's remarks on something that someone at X3J13 said about it:
 ``We want a nice simple rule that everyone can understand.
   The rule should be "no repeated variables" and should 
   not make "subtle" distinctions like binding contours.
   It should refer to the textual shape of the code.  So even
   LET* can't take repeated variables.''