Things that need more work
What, how should be accessible from scripts?
Remark that we call them stacks independently of their implementation: the CallFrame and EvalFrame stacks are actually linked lists, the evaluation stack is a contiguous region of memory.
Why are the CallFrame stack and the evaluation stack defined on a per interp basis?
The execution flow nests perfectly on a per thread basis (per muThread in NRE), maybe there is an issue on interp deletion? If they could be unified ...
The evaluation stack should maybe become "one per thread" . This relies on the fact that Tcl bytecodes are always stack neutral - on return, they leave the stack at the same position they found it. This should improve the memory efficiency of Tcl.
We are now at:
Is this optimal? Costs & benefits of unifying?
My first impression is: one EvalFrame per muThread and one CallFrame per interp are harmless at worst; I do not immediately see a reason to unify them. The evaluation stack should maybe become " one per muThread" (see above).
There *may* be an issue with async calls in the same interp, if and when async is " a different thread of execution in the same interp" !
Should it be part of this framework?
Should we define new Tcl_Obj types for EvalFrame, muThread or other structures? I guess it will depend on the desired script level functionality.
In order to debug the code, it is sometimes useful to make it run in stackful mode - otherwise, all the info in the C backtrace is (obviously and purposefuly) gone.
I'm sure this stuff will need better explanations, forever and ever.
Orthogonal possibilities: