Over on the CONST thread, I mentioned a property of generic quoting that I found disconcerting, in that it subverted CONSTness. Because there was no other clean way for the API to bypass an "evaluative wave of constness" otherwise.
I resolved to put my discomfort aside, and accept that generic quoting offers a way for things to be put into an evaluative situation...behaving as-if they had been accessed by a WORD!. Because sometimes (e.g. in the API or when COMPOSING) you don't have a word to access through...to get that behavior if it's what you wanted.
The proposed workaround for when that const subversion was not intended was that people use @ (...) instead of '(...) in cases that they wanted the constness to match the flow of the block.
Which reminded me of the situation in this thread...
The two connected in my head, to ask the hypothetical question what if quoted things had their binding left untouched...as if the thing you get had been fetched by a word, instead of subtracting a quote level?
some-rule: [num: 10]
make object! [rule: some-rule, num: 20]
; word access, no binding influence on RULE
make object! compose [rule: (some-rule), num: 20]
; becomes make object! [rule: [num: 10], num: 20]
; following the (...) is don't splice and ((...)) is splice convention
; today this would virtually bind NUM in the rule member into the object
; so from RULE's point of view, NUM is 20
; but thanks to virtual binding, SOME-RULE is unaffected
make object! compose [rule: '(some-rule), num: 20]
; becomes make object! [rule: '[num: 10], num: 20]
; because COMPOSE keeps the decoration on the composed thing
; what if the quote subverted the virtual bind, as in the WORD! case?
; so the NUM is seen however it was in SOME-RULE?
A wild--but promising--thought.
Though it raises the question of how things in quotes would ever get bound--such as the SOME-RULE inside of '(some-rule). So if this technique were used, it couldn't apply to all bindings.
But where it did apply, it would mean using a literalizing operator that didn't employ quotes (like what is proposed as JUST) more than we do now. And there would be a lot of unbound things, since most quotes aren't programmatic with QUOTE or COMPOSE.
When this was in effect, you couldn't write stuff like get 'x (which you wouldn't usually, because you could say just x or :x)...but you'd have to say get/any just x instead of get/any 'x. If you were going to write if condition [[a block]] that would be different from if condition '[a block].
It would mean that append block [x] and append block just x would mean something different from append block 'x.
It has a plus side in data exchange. I've talked about the hazards of "stray bindings", not only do they offer possible unwanted linkages to internals of things that weren't intended when using words as a kind of enum symbol, they also hold GC things live which they may have no interest in.
PARSE's mechanics for recognizing things literally wouldn't be affected, as bindings aren't heeded by the matching process. parse [[a] [a]] [some '[a]]
Anyway... I just saw some potential synergy with the "act like you got it from a word" issue run up against in const. I've mentioned how the problems that you run into with the API are no different than the issues you run up against with COMPOSE when you don't have getting things out of a variable...which is why rebQ() is so important...but it also points out that this comes up in non-API scenarios, like this binding problem.