Some history: Rebol2 did not have the idea of allowing groups in paths.
You could put GET-WORD! in paths, and they would be looked up:
rebol2>> block: [a b c]
== [a b c]
rebol2>> index: 2
== 2
rebol2>> block/:index
== b
(Ren-C actually prohibited GET-WORD!s in paths, though interestingly the syntax is becoming legal again with CHAIN!...though it won't have anything to do with "getting")
But generally when you said block/index
it took you literally:
rebol2>> block: [foo 10 index 20 bar 30]
== [foo 10 index 20 bar 30]
rebol2>> block/index
== 20
DocKimbel believes (or at least, at one time said) that adding GROUP!s*cough*
PAREN!
s into paths was a mistake because it complicated the model. I don't think it was a mistake, but it certainly did bring a lot of questions... including the order of evaluation questions.
Some stuff from way back:
Parenthesized expressions on left for SET-PATH! evaluate after right hand expressions · Issue #2275 · metaeducation/rebol-issues · GitHub
We can look at fundamental behaviors, like:
obj: some-obj
obj.field: (obj: some-other-obj, 20)
You might argue that you need to lookup OBJ to the instance of the object it resolves to and remember that, before running the right hand side which disrupts it. That is technically possible for objects...but if you resolve "immediate" values like TIME! or DATE! and forget the variable that held the immediate, they can't write back to them...due to the fact that all the bits for those types live in the cell, so there's no abstract "address" to resolve to. The closest thing you have to an address is the name of the variable, and then you're back to lookup semantics again.
Anyway, the easier bit to do is to resolve the left hand side groups. But if the left hand side is fully resolved in a way the right hand side can't disrupt, that involves some sacrifices on immediate writeback that are probably not worth making, in the grand scheme of things.