So the easiest way to implement this seems to be as a form of ACCESSOR:
A Dream For Debugging: Generalized Accessors
With that, we could make constructs like:
import [@some-module, exported-name <as> local-name]
;
; or more brief but potentially confusing dialected Rebol-y
;
import [@some-module, local-name: exported-name] ; not an assignment, but...
The accessor could be rigged up so that accesses via LOCAL-NAME see changes in the variable that the module exported as EXPORTED-NAME. The module could perhaps even be unloaded and reloaded, synchronizing the exports. (Not being able to patch a module and reload it without exiting and restarting the interpreter was a pain point for @BlackATTR while debugging modularized QUERY.)
So it's pretty clear that by default, you shouldn't be able to write to a module's state. Since modules can be shared, I don't know if it's ever a good idea (unless you are sure you're the only client of the module?) So writing to the accessors created for imports would be a rare thing.
And it seems like you might want assignment to mean something else--e.g. "I want to take back this variable for other uses, I don't need the module export anymore." So maybe there's an accessor pattern here where writing to the variable "de-accessors" it?
We might consider the nuance of:
g: getter $var
s: setter $var
a: alias $var
Maybe a GETTER can only read, but errors on writes... a SETTER can read and write... and an ALIAS will read, but if you ever write it the accessor is disconnected from VAR and it just holds a new value?
I just realized that even though these are enfix, we can now pass them refinements!
So it could be (a: alias:weak $var) and then setters could be set-only, while an ordinary alias permits both reads and writes where the write will write-through to the original variable... but weak makes writes unlink it from the variable.