Internally to the Ren-C code, the term "Eval_Xxx()" has come to imply one step of evaluation, while "Do_Xxx" will take in something like a block and always execute it to the end. Hence a DO is a sequence of N "steps" of EVAL.
I mentioned in "Re-imagining DO/NEXT" why changing the interface was needed, so that DO/NEXT became a new routine called EVALUATE:
>> var: null >> block: [1 + 2 10 + 20] >> block: evaluate/set block 'var == [10 + 20] >> var == 3 >> block: evaluate/set block 'var ==  ; Notice it did not go directly to `null` when there was a result >> var == 30 >> block: evaluate/set block 'var ; null ; null is only signaled when the evaluation had no result >> var == 30 ; ... in which case the variable you passed in is undisturbed
It has a subtle behavior of leaving a lingering "empty" step before returning null and leaving the variable as-is. This turns out to be foundational. It allows invisibles to remain pending and not run "too soon" (imagine if the last step was actually [comment "hi"] and not , e.g. not being at the end of the block isn't the only way you can wind up in a situation where there's not going to be a value coming from the next evaluation...so the steps need to be consistent).
For this to work, it really does require you to pass a variable in. Even if there was a clean implementation of multiple return values, you don't want to overwrite a previous result on a last potentially-vaporizing step. (The mechanics of how this is done inside the evaluator are actually rather slick, but beyond the scope of this post. Userspace you have to do it by passing in a variable that is potentially left as-is.)
However, I think we can improve this interface now with @words as skippable parameters:
>> block: evaluate @var block == [10 + 20]
If you provide an @(...expression...) or @var it will be quoted and used. If not, it will just take the block to evaluate. That looks nice to me!
Naming Collision: EVAL
When EVALUATE came on the scene, there was already a native called EVAL which did something useful...also, exactly one step:
>> x: null >> eval (lit x:) 1 + 2 == 3 >> x == 3
Hence this EVAL is a very tricky variadic that takes a first normal (hence evaluated) argument, and then re-evaluates it as if the expression had been there all along. You'd have quite a hard time writing such a thing yourself (!) but what it does is use some slippery code to re-feed the evaluator with a previous output cell.
However, I'm not very comfortable with having eval be anything other than a shorter name for evaluate. So what if we made those two synonyms, and called this one reevaluate with the shorthand reeval?
I think that cleans up some confusion, and would bring the userspace terminology more in sync with the C implementation.