Just a quick heads-up: to help the Fetch spec, I'm going to be extending the existing Script Setting Object concept to be usable even when scripts are not running. This won't affect the Stack of Settings Objects, but it will mean that Settings Objects might be passed around when no script is running. I plan to rename the concept to Environment Settings Objects accordingly.

Currently, a bunch of specifications have checks along the lines of "if the JavaScript global environment is a document environment, ..."

It would be good if these kind of checks could be rewritten using this new construct, if we don't want to tie the platform to JavaScript at a conceptual level. (No strong feelings about that either way personally.)

Those can be trivially patched to just check the "specified global object" of the settings object, or some such, but we could also add an explicit "environment kind" which has a 1:1 mapping to that and makes it clearer.

I ended up not adding the environment kind because I couldn't come up with terms that didn't suck or clash with something already. So just refer to the specified global object (or, the global object specified by the environment settings object, or whatever) when testing its type.

Anyway, we now have environment settings objects. You can get them from the global and pass them around, and you'll have everything you need including a reference to the event loop which you likely need for various reasons. I recommend using this widely instead of the "client" concept, "realm" concept, or the global itself, since we can more trivially hang things from it if necessary.