The part that's incompatible with current semantics of symbols is importing that symbol as
an immutable symbolic reference. Not really a "variable" reference, but as a binding
of a symbol to a value in the run-time namespace (or package in CL terminology, although
CL did not allow any way to specify what I'm suggesting either, as far as I know).
An alternative would be to extend the semantics of symbols with two additional immutable bindings - one for constant values and another for constant functions. These would be shadowed by the mutable bindings during evaluation, then (if unset) be bound to the final value assigned to the mutable bindings when the namespace is finalized. Then, when a symbol is imported from a compile time environment, the import would be to the constant (value or function) binding, which could be shadowed by an evaluation-time variable/function.
That should qualify as a consistent extension of the current semantics rather than a modification. It would be a lisp-4 instead of a lisp-2.
Personally, I'd also like to have a way to define a global variable that does not modify the lexical scoping of let for that variable. Say, "defstatic" - corresponding to a variable with static global storage. I kind of hate that the semantics of "let" (or lambda parameters) are determined by the global state at evaluation time.
Lynn