New 64bit tabs will not execute 32bit plugins (e.g., <SL5). Can be enabled without Enhanced Protected Mode (EPP) which is for 64bit isolates tabs to AppContainers which further constrains reads and writes (ideal for high-security for example governments). ASLR = Address Space Layout Randomization and ForceASLR bit is true by default for added security.
"Protected Mode" has been introduced in IE 7 as a mechanism to prevent malware from writing to the registry and file system. However, "Enhanced Protected Mode" is something new. If I interpret these notes correctly, it simply uses the x64 version of IE 10 and isolates tabs in app containers, giving them the same restrictions that Metro-style apps have. Digging a bit further and checking back with friends from the IE team, I got an excerpt from the group policy which reveals:
Enhanced Protected Mode provides additional protection against malicious websites by using 64-bit processes on 64-bit versions of Windows. For computers running Windows 8 and above, Enhanced Protected Mode also limits the locations Internet Explorer can read from in the registry and the file system.
So, x64 IE 10.0 processes + AppContainer + ASLR + Protected Mode (which limits system access) = Enhanced Protected Mode? If so, this would mean an absolute locked-down browsing experience that would also lead to NO plug-ins, but maximum security. I'd enable that mode in a heartbeat.
IE 10 "MoBro" aka "Modern Immersive Browser" aka "MIB" limitations
As we know, Windows 8 ships with two separate versions of IE 10. The traditional, "classic" IE 10 and the Metro-style Internet Explorer app that the IE team refers to (mostly) internally as "MoBro/Modern Immersive Browser/MIB". The notes mention how the two browsers share settings and configurations, but operate "contextually" -- meaning that if you click on a URL in Outlook, the desktop IE 10 opens, while clicking on a URL in a Metro-style app causes MoBro to open.
Also, the note goes on to say how not just Plug-ins and Browser Helper Objects are unsupported in MoBro, but literally all third party interventions, including protocol handlers (think RSS readers). Unfortunately, the IE team is well aware that there is no supported method to determine which "mode" the user is currently in and seems to make no qualms about solving this scenario, which, in my opinion, is a mistake. At least give users the opportunity to switch to classic desktop, when the website includes non-supported content or content that requires plug-ins.