Indeed you can - but I suspect I know why Node has avoided this.

If you did take advantage of the runtime's support for multiple global objects, what would those global objects correspond to? The most natural scope would be "user session" - but if you go that route, now you support stateful user sessions. And before you know it you have developers storing loads of user session state in the server's RAM and wondering why they keep running out - and lose the ability to easily fail over to another server process.

So I imagine Node's author decided it was better to just keep things simple and discourage use of globals.

JS in browsers is not multi-threaded. There's only one JS thread where requests from async calls are queued: http://ejohn.org/blog/how-javascript-timers-work/

When dealing with true multi-threading you have all sorts of issues you need to worry about, like locking for writing, worrying about deadlocks, etc. that make coding much more difficult.

Well I don't think web browsers are really the same thing as server side code. Even individual pages in a browser are sandboxed from each other. Just like individual request/response cycles for a user session probably should be on the server (unless you go out of your way to break that, ie making some variable "static").