- Instead of "in error, please say 'will signal an unbound variable
error', or something similar. Be specific in errors when you can.


To promise that something 'will' signal an error would require the qualifier "in safe code" - (safety 0) disables all boundp checks.

I'm not sure if we are always using carefully guarded language, but I would propose:

"Attempts to read NAME in safe code within COMPILE-FILE will signal an error of
type unbound-variable if NAME has not otherwise been assigned a value.

That unfortunately sounds like it means something about code within the COMPILE-FILE but the more words I stick in, the worse it gets.
"... within the temporal extent of COMPILE-FILE " is misleading because the error will (or should) be signaled any time prior to the variable having been assigned, so it actually can happen up until you load the fasl.  But I feel I have to somehow mention COMPILE-FILE because COMPILE and EVAL will never cause the hard-to-explain behavior.

Any better suggestion than the preceding?

 
 The previous implementation (sans source locations) was
something a user could have rolled on top of ALWAYS-BOUND and GLOBAL
declarations. This one ties into compiler magic.

agreed. I was loathe to implement a new global proclamation that would allow you to hand-roll this though. That sounded like the greater evil.