Develop Reference

Why variable object was changed to lexical environment in ES5?

ES5 changed variable object(VO) to lexical environment. What's the motivation of such change since VO is already very obvious as perception?

I think variable objects are more analogous to environment records.
An Environment Record records the identifier bindings that are created
within the scope of its associated Lexical Environment.
In ES5 there are two different kinds of environment records:
Declarative environment records are used to define the effect of
ECMAScript language syntactic elements such as FunctionDeclarations,
VariableDeclarations, and Catch clauses that directly associate identifier bindings with ECMAScript language values. Object
environment records are used to define the effect of ECMAScript
elements such as Program and WithStatement that associate
identifier bindings with the properties of some object.
So the question would be why declarative environment records were introduced instead of only using object environment records just like ES3 variable objects. The difference is that declarative environment records can have immutable bindings:
In addition to the mutable bindings supported by all Environment
Records, declarative environment records also provide for immutable
bindings. An immutable binding is one where the association between an
identifier and a value may not be modified once it has been
established.
Immutable bindings don't have a direct equivalent in objects. A property can be defined as both non-configurable and non-writable, becoming immutable. However,
Creation and initialisation of immutable binding are distinct steps so
it is possible for such bindings to exist in either an initialised or
uninitialised state.
But you can't have an uninitialized property. If you define a non-configurable non-writable property with value undefined, then you won't be able to initialize it to the desired value.
I don't think it's possible to have uninitialized immutable bindings in ES5. CreateImmutableBinding is only used in Declaration Binding Instantiation and Function Definition, and in both cases it's immediately initialized with InitializeImmutableBinding.
But possibly this was done to allow uninitialized immutable bindings as extensions of the language, like the JavaScript 1.5 const. Or maybe they already had in mind ES6 const.

The same author whose ES3 article you linked wrote also about ES5 (and even linked that section there). I'll quote Mr. Soshnikov from his "Declarative environment record" section in ECMA-262-5 in detail. Chapter 3.2. Lexical environments: ECMAScript implementation:
In general case the bindings of declarative records are assumed to be stored directly at low level of the implementation (for example, in registers of a virtual machine, thus providing fast access). This is the main difference from the old activation object concept used in ES3.
That is, the specification doesn’t require (and even indirectly doesn’t recommend) to implement declarative records as simple objects which are inefficient in this case. The consequence from this fact is that declarative environment records are not assumed to be exposed directly to the user-level, which means we cannot access these bindings as e.g. properties of the record. Actually, we couldn’t also before, even in ES3 — there activation object also was inaccessible directly to a user (except though Rhino implementation which nevertheless exposed it via __parent__ property).
Potentially, declarative records allow to use complete lexical addressing technique, that is to get the direct access to needed variables without any scope chain lookup — regardless the depth of the nested scope (if the storage is fixed and unchangeable, all variable addresses can be known even at compile time). However, ES5 spec doesn’t mention this fact directly.
So once again, the main thing which we should understand why it was needed to replace old activation object concept with the declarative environment record is first of all the efficiency of the implementation.
Thus, as Brendan Eich also mentioned (the last paragraph) — the activation object implementation in ES3 was just “a bug”: “I will note that there are some real improvements in ES5, in particular to Chapter 10 which now uses declarative binding environments. ES1-3’s abuse of objects for scopes (again I’m to blame for doing so in JS in 1995, economizing on objects needed to implement the language in a big hurry) was a bug, not a feature”.
I don't think I could express this any better.

Understanding Web API DOM interfaces

I'm trying to learn more about Web APIs. Reading about them I see that among the wide variety of web API's there's the DocumentObjectModel API. Reading about the DOM specifications, I find a list of a lot of DOM interfaces. This makes me feel a little upset. In my ignorance, I think that an API should contain only one interface (only one set of functions and properties), here I find a list of interfaces...and that's the first thing that I don't understand.
Moreover, I usually interact with the DOM using notations like
document.getElementById("idname");
document.getElementByTagName("tagname");
etc ect
I see that some of these DOM interfaces have names that I already know, like "Document" or "Window", I use them (like in the previous two lines of code) but I use them not capitalized ("document" rather than "Document"). I don't understand if there is a link beetwen "document" and "Document", for example...
Finally, I noticed that querying for the global object (in the browser console, for example, simply typing the keyword "this") I have in response an object that (I guess) contains all the properties and functions (or methods) of the global object. And among them there are also functions that have the same names listed in the DOM interfaces list. And that's simply another thing that I noticed that I'm not able to explain.
So, can you help me to understand more deeply DOM API?

Those things arise from an interaction of javascript and the DOM specifications.
The capital-letter Window and Document are interfaces defined by the DOM and HTML specs.
In Javascript, when executed in a browser environment, an instance of Window is the global object and Window is its prototype. document and window are getter properties defined by those interfaces. Since the window is the global object (the top-level this) and variable name resolution walks up the scope chain and finally lands at the global object if it cannot find it elsewhere window will eventually resolve to <global object>.window. Which is the attribute defined on the Window interface, which returns the window instance itself, which also is the global object. It is self-referential.
So the global object ends up having properties defined by javascript, by the dom/html specs and inherited from the prototypes also defined by those various specs.
Some prototypes are also exposed as named properties in the global object and not just the prototype chain of the instances. This is convenient for instanceof checks and feature detection. Some constructors are also exposed, e.g. new Image() creates a new instance of HTMLImageElement the same way document.createElement("img") would.
Additional Document instances can created via various constructors or factories such as DOMParser. Additional Window instances might be accessed through frames, the page's opener or spawned child windows.
Looking at the window object with a debugger may help.

In web-browsers, is the window object a native ECMAScript object?

The ECMAScript specification defines an "unique global object that is created before control enters any execution context". This global object is a standard built-in object of ECMAScript, and therefore a native object.
The spec also states:
In addition to the properties defined in this specification the global
object may have additional host defined properties. This may include a
property whose value is the global object itself; for example, in the
HTML document object model the window property of the global object is
the global object itself.
So, in web-browsers, the window object is just a convenient name for the ECMAScript global object, and therefore, the window object is a native ECMAScript object.
Did I get this correctly?

This mostly comes down to a question of what it really means to be a "native object" or a "host object". The ECMAScript specification provides fairly abstract definitions of those terms and there is plenty of room for differing interpretations of the definitions. For example, in the definition of native object, what is the word "semantics" actually talking about. Is it just the primitive object semantics (in ES specified by the [[propName]] internal properties) or does it include application level semantics of the object. The DOM window object certainly has observable application level semantics that are not defined in the ES specification, so if those semantics are considered it can't be a "native object".
The answer is probably much simpler if you look at it as a question of implementation pragmatics. A ES engine implementer probably thinks of any object that is allocated in the ES heap and managed by the ES garbage collector to be a "native ES object". A "host object" would generally be thought of something that exists external to the ES heap and that is accessed using some sort of interoperability layer such as COM, XPCOM, or the V8 embedding API. Depending upon the implementation, the DOM window object might fall into either category. This distinction is probably more relevant to both engine implementers and host providers than any of specification level distinctions.
There will likely be further definitional clarifications in the next edition of the ES specification. There is even a proposal to eliminate the "native" and "host" object terminology: http://wiki.ecmascript.org/doku.php?id=strawman:terminology . However, it isn't clear whether such definitions really have very much practical impact.

I could (and probably will) argue that the specification does not require the global object to be a native object. The spec defines a native object as:
object in an ECMAScript implementation whose semantics are fully defined by this specification rather than by the host environment.
And the definition of a host object:
object supplied by the host environment to complete the execution environment of ECMAScript.
The host object definition could certainly be applied to window, it is an object supplied by the host environment to complete the execution environment of ECMAScript. In addition, Its semantics are not fully defined by the ECMAScript specification.
There's also the case that the ECMAScript engines that run in browsers, such as V8, TraceMonkey, etc, do not create the window object. Rather, it is provided by the DOM (constructed and inheriting from DOMWindow or Window, for example).

Yes, your reasoning sounds about right. As a semi-proof, when a function is executed without explicit this ("in the global context"), its this will evaluate to window inside the function body. But this is really JSVM-specific. For example, have a look at this v8-users message (and the related discussion.) Things are a bit more complicated behind the scenes, but look approximately as you describe to the user.

What triggers JavaScript code execution?

In case you don't know what I'm talking about, please read John Resig - How JavaScript Timers Work and Is JavaScript guaranteed to be single-threaded?
There are several triggers that enqueue tasks in the JS engines' execution FiFo. This is not part of any standard, so I'm trying to find an exhausive list of those triggers. (I guess it all boils down to internal event handlers, like script load events or timer events, but I'd rather ignore the engine's internals and look at things from the user's point of view.)
So far I have identified
<script> elements in the initial document (including the ones added by document.write)*
<script> elements inserted by JS at runtime*
Event handlers
-- these include a wide variety of cases, such as user interaction, Error events, Web Worker messages or Ajax callbacks ...
window.setTimeout
window.setInterval
*) only in Browser/DOM environments
Any more? Any differences between JS engines?

"JavaScript" as a language name should not really be used it is too broad.
ECMAScript is what you are referring to. You can find information on ECMAScript at http://www.ecmascript.org/
The language standard is called ECMA-262 with the 5.1 Edition supported by most browsers.
setTimeout, setInterval, DOM events, and more are not part of the language. These are provided by the host environment as host objects. Writing ECMAScript for a wide range of host environment should take special care when using host objects.
ECMAScript code is executed within an execution context. This takes the form of a stack and will hold the state of the current execution context at the top.
There are 3 ways to push an execution context. Global code, eval, and function. This is the only way to start code. Host environments will use these methods to execute code.
The host environment can supply a call stack. This is used to stack function calls generated by host objects which may run in independent threads. Typically an event such as setTimeout will add a function to the call stack. The host environment will then wait until the execution context stack is empty then pop the function from the call stack, create a new execution context, execute the code until completed. It will repeat this until the call stack is empty.
Attempting to build a comprehensive list of host object execution context managers is futile.
To answer the questions.
Any more?
Yes there are many more. This is beyond the scope of this answer. Refer to the particular host environment you wish to use.
Any differences between JS engines? (ECMAScript Host environments).
Yes. Again this beyond the scope of this answer and dependent on the host
There are dozens of host environments, with new ones created all the time. What triggers the creation of a new execution context is highly dependent on the host environment.

In CouchDB shows, what does 'this' refer to?

I'm trying to understand CouchDB and couchapp, and as I'm going through I'm seeing a dearth of the use of 'this' in any given context. I understand that show objects get the document and the request, and are allowed to operate on them with lists and views. These operations are all Javascript objects. But CouchApp also seems to store, as strings, all sorts of things: README files, Mustache templates, and so on. It must have access to them somehow. Does the this operator in the context of a show provide access to the design document root in some way, giving one access to objects by some means other than the require syntax?
In Javascript, this has to be defined somehow in every context, specifically "There is a this value associated with every active execution context. The this value depends on the caller and the type of code being executed and is determined when control enters the execution context. The this value associated with an execution context is immutable" (ECMA-262 Spec, 3rd edition, section 10.1.7). What does it mean in the context of an executing CouchDB design doc show function? A view or list function?

The this variable, in all cases (_list, _show, _update) is the design document itself.
(Strictly speaking, it refers to a JavaScript object representation of the design document that contains the list/show/view function you are operating out of.)