This is a tracking bug, both for HTML and for the wider web ecosystem, to see if we can minimize the number of places that use the incumbent global/settings object/realm. Originally this was https://www.w3.org/Bugs/Public/show_bug.cgi?id=26603.

Here is our HTML checklist:

• Same-origin check for contentDocument [Change a variety of entry settings object uses #1541]
• window.close()
• data: URL document origins
• non-initial about:blank URL document origins (see incumbentNavigationOrigin
• Location-object navigate (@bholley says this one probably has to stick around)
• alert()/confirm()/prompt() sandboxing [Use the Window's associated Document for allow-modals sandbox checks #1473]
• print() sandboxing [Use the Window's associated Document for allow-modals sandbox checks #1473]
• postMessage's origin check of "/" and resulting MessageEvent [Which origins to use in postMessage? #1542, Use only the incumbent global in postMessage #1573] (per Which origins to use in postMessage? #1542 this should stay incumbent, at least unless we get rid of every other incumbent usage)
• MessageChannel's ports' owner [Change MessagePort owner from incumbent to current #5728]
• BroadcastChannel's owner [Check BroadcastChannel origin against creation-time current #5729]
• Setting up a worker (see also SharedWorker) [Use current instead of incumbent + entry in worker constructors #1472]
• importScripts [Editorial: use "current settings object" for importScripts #1963]

Other specs:

• Credential Management should incumbent settings object be relevant settings object? w3c/webappsec-credential-management#53
• Blob URLs Stop using the "incumbent settings object" w3c/FileAPI#60
• cssom-view [cssom-view] Stop using "incumbent settings object"? w3c/csswg-drafts#1725 [cssom-view] Remove "familiar with" check for move/resize methods w3c/csswg-drafts#6300
• Sensor API Stop using "incumbent settings object"? w3c/sensors#253
• Battery Status API Checks on allowed usage are specced incorrectly w3c/battery#19
• Upgrade Insecure Requests

If you have other specs that use the incumbent concept, comment here and I will update the OP.