It does appear that MSHTML has an a step in the variable resolution
procedure that acts as if there is an object above the global object,
that holds those element-id properties. It also appears that reading
the properties directly off the global object will also give the
element with that id. This gives two ways to give the same result,
and the two are not equivalent.

Example:

 <div id="foo">foo</div>
 <script type="text/javascript">
   alert([foo, typeof foo, window.foo, typeof window.foo]);
   // alerts "[object],object,[object],object"

   alert("foo" in window);
   // alerts true

   try { foo = 42; } catch(e) { alert(e.message); }
   // alerts "Object doesn't support this property or method"

   window.foo = "window.foo";
   alert([foo, typeof foo, window.foo, typeof window.foo]);
   // alerts "[object],object,window.foo,string"

 </script>
 <script type="text/javascript">
   var foo = 37;
   alert([foo, typeof foo, window.foo, typeof window.foo]);
   // alerts "37,number,37,number"
   // a function declaration also changes both.
 </script>

Using the global object instead of "window" gives exactly the same
result (they are the same object, as reported by "==").

I.e., the scope-lookup appears to match page id's just before it
tests the global object. There may or may not be an object holding
the properties (I'm expecting that there isn't, and that they are
instead resolved by extending the lookup algorithm directly).

The property is not writable, but it does shadow the same property
in the global object.

It appears that the id-elements are *also* properties of the
global/window object, but these properties are not ReadOnly
and can be overwritten. After this, "foo" and "window.foo"
resolves to different values.

And further, if a variable or function with the same name is declared
in the global scope, "foo" no longer resolves to the element with that
id.

Even more interesting, the behavior depends on whether one reads the
property of the global objecct as an element before assigning it
another value:

 <script type="text/javascript">
   // window.bar = 42;        // [1]
 </script>
 <div id="bar">bar</div>
 <script type="text/javascript">
   //alert([bar, typeof bar, window.bar, typeof window.bar]); // [2]
   window.bar = "window.bar";
   alert([bar, typeof bar, window.bar, typeof window.bar]);
   // alerts "window.bar,string,window.bar,string"
 </script>

In the above, if [2] is uncommented, the final alert changes
to "[object],object,window.bar,string". I.e., the action of
*reading* "bar" as the element with that id causes later
references to give the same result.

If [1] is also uncommented, the final alert changes back again.
I.e., if a property of the name is already on the global object
when the element is parsed and added to the DOM, then its name is
not resolved specially and it is not set on the global object.

Ok, this was a diversion. The point is: There global object and
the value of the "window" property of the global object is the
same object in MSHTML, just as in the other current browsers.

My bet is that you can expect that to stay true.

...

To be absolutely sure, you should create a reference to the global
object at the point where it is needed, so you don't rely on a binding
that could be overwritten or shadowed.

e.g.
 var global = (function(){return this;})();
 global.alert(global == global.window);

(which, by the way, alerts "true" in all the browsers I have available,
including in MSHTML :).