As part of IE [1] and Chrome's [2] multi-process architecture, it is advantageous from a reliability perspective (among other reasons) to separate what this spec calls top-level browsing contexts from each other. As an implementation detail, this separation becomes problematic when the two browsing contexts are allowed to have synchronous communications, as this requires [at least] synchronization and often blocking between the two processes.

window.open() is an API that can create a two-way communication link between the opener browsing context and the "openee" (auxiliary) browsing context. The communication is provided between the WindowProxy returned from window.open to the caller, and the WindowProxy obtained via the opener property of the callee. To avoid the implementation problems that arise if a browser tries to process-isolate the caller from the callee in this scenario, browsers will "leash" (my term) the one browsing context to the other such that both belong to the same process. Naturally this defeats the benefits provided by process separation, but is necessary to meet our compatibility, performance, and functionality goals. 

I realize that this is an implementation detail and not applicable to all user agents. However, web developers may want to knowingly exploit the reliability and other benefits of process isolation in their pages, especially when there is a compelling scenario to do so. For example, when the web application curates lists of untrusted links, or uses another service such as an ad framework for which it doesn't intent to communicate with. Process isolation really only makes sense when communication opportunities between the processes are at a minimum (especially synchronous communication).

Today process isolation typically happens at the top level browsing context (e.g., "tab"), but in theory its benefits could be extended in the future to any browsing context, such as those established by iframes.

HTML5 should describe a way for web developers to signal the intent to isolate (at least) at the window.open level. Specifically, when the auxiliary browsing context being established by window.open (when no existing named target can be found) should be isolated. Isolation in this sense should not provide a WindowProxy for synchronous or asynchronous communication to either the opener or openee.

The "noreferrer" link type is an existing [3] signal that allows web developers to describe that the openee should not be allowed to refer back to the opener. The spec currently requires that, under these conditions, the "openee" will be unable to obtain a WindowProxy to the opener via the property of the same name(this is implemented in at least Chrome 32). Today, "noreferrer" does not provide complete isolation because a WindowProxy to the "openee" is still provided to the opener, thus leaving open the option to communicate with the openee. Consequently, browsers do not setup process isolation in this scenario. I suspect it may be web-incompatible to change this behavior by extending "noreferrer" to also not return a WindowProxy from window.open().

I'd propose introducing a similar link type, perhaps "isolate" or "unrelated" to trigger this new behavior: window.open() will not return a WindowProxy in addition to the behavior of "noreferrer". Alternatively, some flag to the window.open call itself, such as a target string "_new" or "_isolate". Or to be more generic, the use of a sandboxing directive or CSP directive [4] similar to "popup-src" but with isolation semantics.

[1] http://blogs.msdn.com/b/ie/archive/2008/03/11/ie8-and-loosely-coupled-ie-lcie.aspx
[2] http://blog.chromium.org/2008/09/multi-process-architecture.html
[3] http://www.w3.org/html/wg/drafts/html/master/single-page.html#link-type-noreferrer
[4] http://w3c.github.io/webappsec/specs/content-security-policy/csp-specification.dev.html#popup-src