No, it's a bug.

[Alan Bawden <ALAN at MIT-MC>]

    Date: 4 January 1981 20:05-EST
    From: Kent M. Pitman <KMP at MIT-MC>

From:         Date:
Date: Tue, 1 Apr 81 18:27:15 GMT
Original-Date: 01/04/81 14:27:15 EDT
Subject:
        From: DICK at MIT-ML
        To:   (BUG LISP) at MIT-ML

        There is a bug in macroexpand that is seen in the  following
        scenario ... macroexpand uses a macro even if it is not the current 
        functional property in force....
    -----
    This is a widely taken-advantage-of feature, actually. ...

This is not the not-so-widely taken-advantage-of feature that I am
familiar with, look again:

(defun bar macro (body) (cons '1+ (cdr body)))
BAR
(defun bar (x) (+ x x))
BAR
(bar 4)
8
(macroexpand '(bar 4))
(1+ 4)

bar is defined as a macro first and THEN redefined to be an expr.
Eval and apply will BOTH find the expr property, the function bar has
been 100% redefined to be (lambda (x) (+ x x)).  You may recall that
defun (and defprop) go to a great deal of hair to move properties to
the front of property lists so that such redefinitions work.

Now there is this kludge where apply, mapxxx, funcall, etc. ignore a
macro property in favor of one that can be applied, but that is a
kludge in the language to fix a defficiency (at small expense, since
nothing that otherwise works is effected), and it doesn't imply a
general philosophy that macro properties must ALWAYS represent correct
translations.  You HAVE to be able to redefine a macro as an expr
(with a possibly different definition) and have everybody agree on it.
If you wish to make shadowed macro properties mean what you suggest,
then defun had better start doing remprops of macro properties.

This is a real bug in macroexpand, and it should be fixed.