Rebol has historically relied on the idea that when you import declarations from a library, the importing context gets a new variable to back each word you use.
I explained this in "The Real Story About User and Lib Contexts". A central idea is that if you didn't get your own copy, then a simple statement like print: panic/ would corrupt the notion of PRINT as used in the Mezzanine.
But it's not always helpful. When keeping your own copies is a requirement, it can be a big impediment to transitioning a non-modularized codebase to a modularized one... as I noticed in 2021 with the first modularization of the Whitespace Interpreter codebase:
But Now, We Have DUAL-state Variables...
I've called antiforms "a quoting level of -1"... a bizarro upside-down world of interpretation, where whatever your base type was has gone to a whole different meaning. BLOCK! antiforms become PACK!s that decay to their first element and are unpacked by SET-BLOCKs. GROUP! antiforms become splices that merge into appends without the enclosing list.
It's a stylized trick that creates new "magical" types, but that easily transform into their non-magical forms... so we don't have to worry about coming up with all new formatting or modification methods for them. Do a little fiddling with the quote byte and that SPLICE! is just a plain old GROUP! that you can measure the length of or pick items out of just as you could a non-splice. The rendering of a PACK! quasiform is just a little spin on the rendering of a BLOCK!, and you can work with it as well.
Dual states push this trick a little further... to what might be called quoting level -2. This subterranean level of representation isn't something you can produce from an evaluation... and you can't get it into a variable with SET or read it with GET. The meaning is always something "beyond", that influences how SET and GET of that variable will operate in a fundamental way.
The way you set things at this level is with TWEAK (or constructs that call TWEAK to implement their behavior). For lifted states, TWEAK is just like SET of the unlifted thing:
>> x: ~
>> tweak $x first ['10]
== '10
>> x
== 10
>> tweak $x first [~null~]
== ~null~
>> x
== \~null~\ ; antiform
But for non-lifted states, TWEAK has special meaning. One of these I'm working with is ALIAS for pinned values:
>> y: 1020
>> tweak $x @y
== @y
>> x
== 1020
(There's clearly potential for infinite recursion and other badness here, so assume there's some sort of depth limit.)
When you do an IMPORT, we should be creating these aliases by default...not copying the value directly.
We can imagine a "hard alias" where overwriting X would overwrite Y:
>> x: 304
>> y
== 304
And we can imagine a different TWEAK where overwriting X would just be a new definition, leaving Y alone, maybe with $ instead:
>> tweak $x $y
== $y
>> y
== 304
>> x
== 304
>> x: ~null~
== \~null~\ ; antiform
>> y
== 304
I think this sort of mechanic could work for granular imports. Then there could be a more efficient "assume you want everything, but read only"--where you don't have to make itemwise aliases--and it just uses the normal "environment" mechanism to add a module USE link in the inheritance chain.
With tools like these (and a language in IMPORT and BIND to use them) I think many of the true pain points of modularization and binding in general can be addressed... of course, with the cost of more complexity... as a variable can be much more than simply the value that it holds. (Nothing is free... 
... you'll be able to make objects that you copy where the copies will not be behaviorally symmetric with the "value captured" version they copied.)