So... deleting this information does seem lossy. It's helpful to see when something uses non-local declarations.
But the premise of the language is that you get these things as visible by default.
Some time ago I wondered about the idea that only functions would have this visibility, and any non-functions you would need <with> to see and modify.
Today that would mean you'd have to explicitly bind it:
global-var: 10
foo: function [
arg1 arg2
]
bind @global-var [
global-var: 20
return arg1 + arg2
]
But this feels like an uphill battle, and you're probably inconveniencing as many or more situations than you are clarifying.
Perhaps it's better to just count one's small victories...e.g. that you have to pre-declare global-var, and typos like globl-var: won't work.
A lot of these cases are really situations where you should make an object with data members and methods, anyway... vs. have some sneaky relationship between global variables and certain functions.
I decided to tolerate <with> in the specs for now
What the native code actually does is a better-than-nothing enforcement, that it checks to make sure the thing you mention for with has a binding. This caught some stale <with>.
and... I Might Bring Back <static>
Since I've been able to easily implement the <local> initialization feature, as well as settle on why it uses a WORD!+GROUP! instead of a SET-WORD, I might be willing to add the feature back.
But as that thread explains, the notation of WORD!+GROUP! limits you in terms of what you can do with your assignments. The workaround for locals is to put the assignments in the body. The workaround for statics is to use BIND.
I'll weigh the pros and cons, but for right now BIND is getting exercised...and the PARSE wrapper that slowed down every function generation is gone.