I started exploring this, and found that we're still using this logic (incorrectly) to produce a DynamicScope for parsing evals in a given context. It's incorrect because when we actually run the evals, they get their own DynamicScope instances. The reuse of a single scope for all evals in a context causes their local variables to be offset as if they could all see each others' definitions. This causes eval dynscopes to be larger than necessary (and may represent a leak if you are evaluating many different local variable names in a single scope).

I'm looking at removing the logic you mention and fixing this issue now.

I have figured out the mystery of the index growing. IREvalScript will ask for variables from a special variable stash in the nearest non-eval IRScope. In essence, IR solves the variable sharing its own way. Tantalizingly just deleting this code and running things makes several evals work as expected but there is still something I have wrong.

The plus side is IR Eval can get much simpler. IR was started at a point when we still had to support lvars being captured across evals. Now that this is gone most of the craziness of evals in IR will go away. I will maybe get @subbuss to help me now that he is back home :)

Given that I got home 30 mins back .. maybe over the weekend :)

I am calling this as done for now. Behavior of binding is still a little weird but only because we clone bindings because we modify the binding during evals (and we have done this for a long time). We should untangle this once and for all but it will be done later when we tackle block/eval call protocol in IR.