I found this case because CCL totally chokes on it. (In addition to other error I mentioned about TYPECASE in general).
In fact they disagree that SBCL's treatment of consecutive (let's not say "nested") conditionals is right.  See bug report I filed:

#1112: #[-+] reader macros don't nest correctly
--------------------------------+-------------------------------------------
 Reporter:  dkatzman            |       Owner:
     Type:  defect              |      Status:  new
 Priority:  normal              |   Milestone:
Component:  ANSI CL Compliance  |     Version:  trunk
 Keywords:                      |
--------------------------------+-------------------------------------------
 This function prints (C), (B), (B), (A) as tested under SBCL and CLISP on
 x86/darwin.

 {{{
 (defun test ()
   (print (read-from-string "#-x86 #-darwin (a) (b) (c)"))
   (print (read-from-string "#-x86 #+darwin (a) (b) (c)"))
   (print (read-from-string "#+x86 #-darwin (a) (b) (c)"))
   (print (read-from-string "#+x86 #+darwin (a) (b) (c)"))
   (values))
 }}}

 CCL prints (B), (C), (B), (A) by the following rationale:

 In the first test, 'x86' is true so a form must be discarded. 'darwin' is
 true so the '(a)' reads as NIL due to read-suppress being T. NIL is the
 expression skipped by the #-x86 making (b) the next expression.
 etc.

 This is probably what you want:
 {{{
 Index: l1-reader.lisp
 =============
 --- l1-reader.lisp      (revision 15900)
 +++ l1-reader.lisp      (working copy)
 @@ -2950,7 +2950,7 @@
               (values)))))

  (defun read-feature (stream)
 -  (let* ((f (let* ((*package* *keyword-package*))
 +  (let* ((f (let* ((*package* *keyword-package*) (*read-suppress* nil))
                (read stream t nil t))))
      (labels ((eval-feature (form)
                 (cond ((atom form)
 }}}
5:19 AM (2 hours ago)
to openmcl-trac
#1112: #[-+] reader macros don't nest correctly
--------------------------------+-------------------------------------------
 Reporter:  dkatzman            |       Owner:  gb
     Type:  defect              |      Status:  assigned
 Priority:  normal              |   Milestone:
Component:  ANSI CL Compliance  |     Version:  trunk
 Keywords:                      |
--------------------------------+-------------------------------------------
Changes (by gb):

  * owner:  => gb
  * status:  new => assigned


Comment:

 I don't know of anything in the spec that says anything about how nested
 conditionals like those in your example should be handled.  If you know of
 such things, I'd be interested in hearing of them.

 You can certainly say that CCL differs from other implementations in its
 handling of cases like this; as I said, I'm not sure that that either
 behavior is any more or less correct than the other (or than other
 plausible behaviors.)

 <http://www.franz.com/support/documentation/8.2/doc/implementation.htm
 #nested-conditionals-3> discusses how Franz addressed the fact that their
 implementation had different behavior than other implementations (and than
 CCL), and I think that their solution is probably reasonable.  (There's no
 compelling reason to be arbitrarily different from other implementations
 in this case, but changing an implementation's behavior could break
 existing code and there likely needs to be some simple way to revert to
 traditional behavior.)

 If we don't do this, it's likely only a matter of time before someone says
 "this behavior is incorrect, because it's not what I see in Acme Common
 Lisp", and it's not worth having that argument.


On Wed, Sep 18, 2013 at 6:27 AM, Christophe Rhodes <csr21@cantab.net> wrote:
Douglas Katzman <dougk@google.com> writes:

> This function attempts to read an expression that resembles a similar one
> in DUMP-I-VECTOR:

Right.  Whoops.  I've rewritten DUMP-I-VECTOR to remove the specific
problem (not a problem in practice because of the constraints on the
cross-compiler, but even so) and make the function more comprehensible
in general.

> A few things would make this kind of construct more concise and legible:
> 1. Avoid #![-+] when the feature expression following is just (AND) or (OR)
> stuffed in by a read-time eval of an arbitrary Lisp form. It makes no
> difference whether that "feature" is evaluated with respect to host or
> target features. Better still, add a :64-bit feature which replaces the
> somewhat obscure expression
>   (cl:if (cl:= 64 sb!vm:n-word-bits) '(and) '(or))
> with just
>   #!+64-bit

Or #!+#.(sb-cold:64-bit) if we want to avoid namespace issues, but yes.

> 2. Avoid nesting of the macros - it's not very clear.

Indeed.  How did you find this case?  I toyed this morning with trying
to write something which prohibited nesting #- inside #!- (and the
converse) but couldn't really convince myself that it was completely
desireable.

Thanks,

Christophe