Whenever a script is running, it has a so called "execution context". For every Program, function call and call to eval (and setTimeout and setInterval), a new execution context is created. These are put on a stack, where the top of the stack is called the "running execution context". Whenever the code encounters a return statement, the running execution context is removed and the next context on the stack becomes the running context. A throw may dismiss multiple contexts from the top, until it is catched (or the program ends).
Every execution context has properties that tracks the state of the current execution. It will at least have the following properties:
- LexicalEnvironment
The top Lexical Environment for this execution context. This is where Identifier resolving starts. Initially this is equal to the VariableEnvironment, but it may change (how?).
- VariableEnvironment
This is where variables are bound to. This is what you mean when you refer to the "local scope". This value, once set, never changes for this execution context. Initially this is the same as the LexicalEnvironment.
- ThisBinding
The value associated with 'this' in the current execution context.
The type of the LexicalEnvironment and VariableEnvironment properties are always a Lexical Environment. Their initial value is determined by the way this execution context was spawned, defined in 10.4.x. The contexts coexist next to the scope tree. When a context is created for eval or function code, the current Lexical Environment is set as the base for this context. In case of strict eval code, another level of Lexical Environment is put in between so you can't directly manipulate (but still access) the underlying environment.
It is not possible to manipulate or even see the concept of execution contexts from within Ecmascript. It's used for specification only, so internally, it might not even have these concepts (but it must still behave as if it did).