Should IS try to decompose macros?

[phoe]

5AM> (let ((x nil))
       (or (null x) (zerop x)))
T

5AM> (test is-evaluation 
       (let ((x nil))
         (is (or (null x) (zerop x)))))
; in: NAMED-LAMBDA %TEST-IS-EVALUATION
;     (ZEROP IT.BESE.FIVEAM::X)
; 
; caught WARNING:
;   Derived type of IT.BESE.FIVEAM::X is
;     (VALUES NULL &OPTIONAL),
;   conflicting with its asserted type
;     NUMBER.
;   See also:
;     The SBCL Manual, Node "Handling of Types"
; 
; compilation unit finished
;   caught 1 WARNING condition
IS-EVALUATION

5AM> (5am:run! 'is-evaluation)

Running test IS-EVALUATION X
 Did 1 check.
    Pass: 0 ( 0%)
    Skip: 0 ( 0%)
    Fail: 1 (100%)

 Failure Details:
 --------------------------------
 IS-EVALUATION []: 
      Unexpected Error: #<SIMPLE-TYPE-ERROR expected-type: NUMBER datum: NIL>
Value of X in (= X 0) is NIL, not a NUMBER..
 --------------------------------

NIL
(#<UNEXPECTED-TEST-FAILURE {120B7FA3A3}>)
NIL

That is because IS disassembles OR, disregarding the fact that it's a macro, and tries to manually evaluate its components. A "fix" is to use IS-TRUE instead of IS.

Should there be a check if IS receives a macro form, at which point it can "devolve" into something like IS-TRUE, instead of trying to be too smart for its own good?