...A Grand Unifying Theory??
I think GET, SET, PICK, POKE, PATH!, and SET-PATH! should all be running on the same basic hook. I've explained why that hook being recursive makes sense for POKE.
What if a GET has a secondary return value, which is the reusable sequence of steps?
>> obj: make object! [x: 10]
>> tuple: obj.(print "!! SIDE EFFECT !!", 'x)
>> get tuple
** Error: Use GET with /GROUPS: output to evaluate sequences with GROUP!
>> [result steps]: get/groups tuple
!! SIDE EFFECT !!
== 10
>> steps
== $[obj x]
So GET and SET can interpret that $-block as steps... basically a TUPLE! that has had its group elements processed (and hence may contain elements not typically legal in tuple).
>> get steps
== 10
>> set steps 20
== 20
>> obj.x
== 20
Preliminary Tests Of This Idea Look Promising 
There's still a lot to mull over with this, but it's the cleanest-looking angle I've come up with yet.
Errors are still a bit of a puzzle. Once you've converted a TUPLE!/PATH! into one of these "steps blocks" then you've gone away from the source level of what the user wrote. The later SETs and GETs will only have the block--presumably not the path.
(Note: Though you could save it and pass it in? Maybe the original path could be cached as part of the block, as a kind of commentary used in error delivery?)
In any case, when you use the steps later you have less odds of erroring since the initial path access that returned the steps block worked. We'll have to see how it pans out.