Default scope of references

[Dan Hoey <hoey@nrl-aic.ARPA>]

I would like some protection against accidental references to
dynamically bound variables in interpreted code.  Compilers typically
complain about such lossage.  When I heard that Common Lisp defaulted
to lexical binding, I thought that was what was meant.  For instance,
given

(DEFVAR *TEST-1* '(PROGN (DEFUN SET-FOO (VAL)
				(SETQ FOO VAL))
			 (SET-FOO NIL)))

(DEFVAR *TEST-2* '(PROGN (SET 'FOO T)
			 (DEFUN GET-FOO ()
				FOO)
			 (GET-FOO)))

in the absence of (PROCLAIM (SPECIAL FOO)), I somehow expected that
(EVAL *TEST-1*) and (EVAL *TEST-2*) would each tell me that I was
accessing a variable that was neither declared special nor lexically
bound.  According to CLtL, however, ``The general rule is that if the
symbol occurs textually within a program construct that creates a
*binding* for a variable of the same name, then the reference is to the
variable specified by the binding; if no such program construct
textually contains the reference, then it is taken to refer to the
special variable of that name.'' [p. 55]  Thus these forms are
supposedly legally evaluable.  Is this what was intended?  Should
evaluation of these forms be or signal an error?  I would certainly
hope that the answer is the same for both tests.

The CL interpreters I have seen signal an error in (EVAL *TEST-1*);
they are happy to let (EVAL *TEST-2*) modify the global value of FOO.  
A funnier situation occurs when we have

(DEFVAR *TEST-3* '(PROGN (EVAL (BUTLAST *TEST-1*))
			 (DEFUN LEX-TEST ()
				(LET ((FOO T))
				     (SET-FOO NIL)
				     FOO))
			 (LEX-TEST)))

I have actually seen an implementation for which (EVAL *TEST-3*) yields
NIL, but that is clearly erroneous.  Other implementations happily
evaluate *TEST-3* to T, setting the global value of FOO to NIL.  A
stranger situation occurs with

(DEFVAR *TEST-4* '(PROGN (EVAL (BUTLAST *TEST-3*))
			 (COMPILE 'LEX-TEST)
		         (LEX-TEST)))

In the implementations I have tested, (EVAL *TEST-4*) will signal an
error when SET-FOO attempts to change the value of FOO.

Unfortunately, my access to Common Lisp implementations is confined to
one vendor's Beta release and two other implementations to which I have
no hands-on access.  Rather than disparage anyone's implementation on
such slender evidence, I would like to hear from implementors on the
results of evaluating the four tests in the most current versions of
their implementations.

Dan