It has always seemed very tempting to try and speed up the evaluator by not doing recursions of the evaluator.
For instance: if you're filling the arguments for a call to something like IF, and you see the condition is a BLOCK!, why would you call the evaluator?
Instead, what if BLOCK! cells just had a flag on them saying "I am inert". If you see something that is inert, you don't need to run down a big switch() statement of behaviors to see what BLOCK!s do...just write the cell into the frame and keep going.
Initially, infix was the foil for this...
if x > 1 [block] -> ...
Skipping the evaluator just because you saw an inert block would break any infix operators that took blocks on their left-hand side.
I tried many times to be tricky about this, since making evaluator Levels is not "cheap"--especially now that the evaluator is stackless.
But the tricks had a tendency to get in the way of some other work, and so they were pared back with notes about "fixing them someday."
"Someday" Is Now Never
I just found an attempt to skip the evaluator in some circumstances for quoted things, due to "knowing it could just do an unquote".
But with RebindableSyntax, even that is over... the behavior of quoting can be hooked in a context:
So We Won't Skip The Evaluator, Just Speed It Up
I'm looking for more cross-cutting performance improvements.
The move to taking branches literally is actually a fairly important one--to save on computing GROUP!s on branches that don't run.
Letting users do their own explicit modifications--like by using literal branches--seems better. I think the more optimization tools that people have in their hands, they'll be able to apply them to the macroscopic (and even microscopic) places that matter most to them.