Likely relevant is that I'm pursuing "fully pluggable" evaluators; where you can reuse as much or little of the base evaluator behaviors in a dialect as you like.
This is much like how UPARSE is wired together with a map of COMBINATORs. There are generic ones (like the combinator for WORD! or GROUP! or SET-WORD!). Then more specific ones, like for SOME and INTO. You can override them or replace them entirely, and inherit behaviors for your own derived combinators (with some limitations, an overridden combinator cannot currently delegate variadically to a combinator with a different parameterization than its own...not saying it's impossible, but you can't do it at this moment).
By analogy, this would let you customize the base experience of running "DO" code as a map of EVALUATORs.
So if you wish to have something that's "a lot like plain DO, except PATH!s act differently" then you can run a block with a new mapping for PATH! => an evaluator that you write. (That's something that Redbol needs, because the current compatibility method is bad and is holding Ren-C back.)
In the past, people have tried to accomplish evaluator re-use by looping and using DO/NEXT, maybe intervening a bit on steps they feel like tweaking. I've grumbled that I don't think that's particularly great, because it enforces DO being an amnesiac that can't build up state (like new LET variables):
Pivotal Design Question: Is Evaluator State Just A Block?
There still needs to be binding, and I've said quite a bit on that, with a hard-core belief that we do need scopes and string interpolation. But I think some of these dialect behavior issues may be best dealt with via parameterized evaluation, vs. something more intended for users to provide variables to those dialects.