#+ reader should insist on seeing a next form

[Douglas Katzman]

(read-from-string "(let ((foo 3) #+sbcl) wat)") => (LET ((FOO 3)) WAT)

This is not a regression. The bug is present in ancient versions of SBCL going all the way back to CMUCL.

All other Lisp implementations I tested reported an unmatched parenthesis.

The negative case works fine because the reader *must* eat and discard one form.

[Douglas Katzman (dougk)]

This is fixed, but it adds one more way in which "mismatched parentheses" is printed, when in fact there is no mismatch.
Nikodemus seems to hate that (see bug 558465). I don't mind it as much, but I do have a way to fix all such things, I think.
In fact it will be more robust than the hack that was implemented in 32c95570fd8253caca74ed16cde242b9ed3d08ab because the one-char-lookahead trick falls on its face when there is intervening virtual whitespace.

In other words, a peek-char at this #\' would not inform you that you effectively have "(foo ')":
"(foo ' #+other-lisp bar #+other-other-lisp baz)