실행 컨텍스트 안의 VariableEnvironment 를 존재 이유가 궁금합니다.

------- 공식스펙 (1) ----------
https://tc39.es/ecma262/#sec-block

1. 1. Let oldEnv be the running execution context's LexicalEnvironment.
2. 2. Let blockEnv be NewDeclarativeEnvironment(oldEnv).
3. 3. Perform BlockDeclarationInstantiation(StatementList, blockEnv).
4. 4. Set the running execution context's LexicalEnvironment to blockEnv.
5. 5. Let blockValue be the result of evaluating StatementList.
6. 6. Set the running execution context's LexicalEnvironment to oldEnv.
7. 7. Return blockValue.

------- 공식스펙 (2) ----------
https://tc39.es/ecma262/#sec-execution-contexts

An execution context is purely a specification mechanism and need not correspond to any particular artefact of an ECMAScript implementation. It is impossible for ECMAScript code to directly access or observe an execution context.

-------------------------------

제가 확인한 VariableEnvironment가 사용되는 유일한 케이스는
with구문 또는 block scope와 관련이 있습니다.
그 중 block scope는 별도의 execution context를 생성하지는 않고,
현재의 execution context를 유지한 상태에서
'임시의' LexicalEnvironment만을 생성하여
그 내부에서 let 또는 const로 선언한 변수들을 관리합니다.
그러다가 해당 scope가 종료되는 시점에는 다시
원래상태의 LexicalEnvironment로 복구해야 하는데,
그러기 위해 VariableEnvironment가 참조하고 있는
(원래의 LexicalEnvironment도 동일하게 참조하고 있는) 변수들을 찾아 복구합니다.

공식 스펙(1)에는 위와 같은 내용이 명시되지 않았습니다.
다만 이렇게 해석하는 글을 많이 봐왔기에 소개드리는 것입니다.

오히려 공식스펙(2)에서는,
"이런 개념은 어디까지나 순수한 메커니즘에 불과하다"고 하여,
모든 자바스크립트 엔진이 "정확히 이렇게 동작하도록 구현되어 있어야만 한다"는 식의
강제성이 없음을 명시하고 있습니다.
즉 어떤 자바스크립트 엔진이 내부적으로 아예 VE를 구현조차 하지 않았더라도
전혀 문제되지 않는 스펙인 것이죠.

그러니까 'VariableEnvironment는 개념상 이런 존재로구나'
정도로만 파악하고 넘기시길 추천드립니다.

혹시 보다 정확한 자료를 찾게 되신다면 공유 부탁드릴게요!