I would recommend using a completely separate root for the external and internal certificates, to prevent any information leak about internal hosts or users, through Root01, but also prevent any implicit trust by broken software. By using 2 separate root for external and internal use, theres no possible for any trust to leak from External to Internal certificates, regardless how broken the software is.
Normally, if we have certification paths that looks like this:
Root01 --> SubCA01 -> Cert01
Root01 --> SubCA02 -> Cert02
And SubCA02 is imported as trusted. In a valid PKI implementation, Cert01 should not be trusted. But as you know with lazy coding, broken software, and hacky parsing of certificates, theres is possible for trust to leak over from subCA02 to Root01 and thus leaking over causing Cert01 to be trusted by someone that shouldn't trust that cert, if the PKI implementation is very broken and, for example assumes any higher cert as trusted automatically. Yes its far fetched, but better account for any broken software by using completely separate roots instead.
I would also add a PathLength=0 Basic constraint, preventing the CA certificate from being used to sign other CA certificates, in addition to the name constraint.
As you might know, there is lots of broken software out there, and a privilegie escalation attack (as you call it when someone manages to sign a certificate in violation with the constraints) can happen, for example if the said PolicyExt01 certificate is used to sign a subordinate CA, that in turn is signing a S/MIME certificate.
Some broken software only checks for example naming constraints "1 level Deep", and adding a Pathlength constraint would then cause longer chains to fail instead of being accepted as trusted.
So I would do like this:
Root01 (Name constraints = Emailemail@example.com, PathlenConstraint=0, EKU=Message signing)
Root02 (Internal applications, not trusted by 3rd parties...)
And then sharing Root01 cert with those third parties that should trust it, while installing both Root01 and Root02 in all Company-internal computers.
Both Root01 and Root02 is then self-signed root CA certificates.
When using Namingconstraint, I would only put a Emailfirstname.lastname@example.org Naming constraint, and then put every other naming constraints (IP, DNS, UPN, URI) as wildcard excluded, to prevent a certificate from being used as for example a website SSL certificate, if a broken browser or SSL implementation would be unable to parse the key usage flags.
A good idea is also to test your setup, preferable by exporting the root CA certificate and private key to a secure offline computer, and then attempt to sign "invalid" certificates with this. Then test the "invalid" certificates with common client software to ensure the constraints are kicking in and marking the certificate as untrusted.
I do not personally know any explicit configuration that would cause such a "privilege escalation" attack, but as you know, theres lots of broken SSL implementations and PKI software out there, so better be safe than sorry and restrict the certificates as much as possible, and also use separate roots to prevent any trust leak between the certificates by VERY broken software.