The point I was trying to make in "Rebol and Scopes: Well Why Not?" wasn't so much that there can't be some behavior. It's the question of whether that's the behavior that people intend.
If I have a block containing some terms--and I pass it to "someone else" to grok--what happens when some of those terms are meant to have values ascribed by the someone else, and others are supposed to carry over values supplied by the caller?
Ultimately there's no such thing as magic, and you need to have nuts and bolts available to say what you mean. To give some insight into what kind of thinking a seemingly simple binding problem requires, I wrote up the following:
Custom Function Generator Pitfalls
And that's really just two contexts in play: the function generator and the incoming material for the function body. People cobbling together source from lots of places with more complex rules about what lookups apply under what rules can get arbitrarily strange.
In something like PARSE, one avenue of attack is just to use keywords. A mapping from keywords (and types) to combinator functions gives the behavior that parse knows about. If a WORD! is encountered that's not in the mapping, it's only then that the binding is consulted.
>> rule: ["a" "b" try "c"]
>> parse "abababcab" [some [rule (print "found")]]
found
found
found
found
== ~null~ ; isotope
SOME and RULE are both words. But SOME exists in the mapping of combinators, and RULE does not. So after RULE is seen to not be in the map it falls back onto the binding to look it up.
I've thought that GET-WORD! might be a way of subverting keyword lookup and forcing the use of binding:
>> some: ["a" "b" try "c"]
>> parse "abababcab" [some [:some (print "found")]]
found
found
found
found
== ~null~ ; isotope
PARSE also has the problem of wanting to be able to define variables via something like LET internally to the parse, and imagining how this would work is all very new.
Anyway having bindings "stick" isn't the problem...it's when you are weaving together code with mixed wishes. And those wishes have historically been managed by a very simplistic model, that goes so far as to say that each method for each instance of an object has to do a full copy of the function body just so that it can be patched up so the WORD!s point to the object instance. :-/