> A strict (non-leaky) abstraction interface is necessary 
> for being able to re-use the instruction code in an
> alternate evaluator.

The problem is that we don't have a strict (non-leaky) abstraction and I don't think we should impose one.

> Done properly, there should be very little need to move
> between instructions.h and ceval.c to understand what is happening.

I believe that is just wishful thinking and the separation will make it harder to learn and reason ceval.c.   Also, I really don't like putting the essential core of instruction code in a .h file rather than a .c file.

FWIW, when I've done my own experiments with alternative evaluation techniques (such as subroutine threading), it always required changes to the instruction bodies (in part because interesting variants use different argument passing techniques and in part because of a need to change state external to the instruction body for tracing and whatnot).

Overall, I think the proposal would be a net detriment to future maintenance and would not have a recurring payoff beyond your present experiments.