The "official" X.509 stance on rogue CA is that rogue CA are out of scope of X.509. It takes some effort to accept that... The idea is that all the CA structure is not really about preventing attacks, but rather being able to point fingers at the culprits. If a CA goes rogue, then the fraudulent certificate chain will allow to pinpoint which CA got it wrong, and thus direct blame where it is due.
Most browsers deal with the issue about name constraints by not supporting name constraints at all, which means that trying to restrict a sub-CA to a specific domain is, for now, a fool's quest.
IF the support of name constraints was wide-spread, then you could restrict a sub-CA to issuing SSL/TLS for a specific domain by adding a name constraints that forces the subject DN to a prefix that defines the CN to a value that cannot be a FQDN for a machine. Thus, any "SSL aware" certificate would necessarily need a SAN extension, thereby avoiding the problem you allude to. But this still makes assumptions on the behaviour of implementations that encounter a certificate whose subject DN contains multiple "CN" fields; if the SAN constrains the DN to "CN=INVALID FOR DOMAIN", and the rogue sub-CA issues a cert with, as DN: "CN=INVALID FOR DOMAIN,CN=www.google.com", how will client software react ?
To sum up, name constraints don't work well or at all in practice, for lack of widespread support, but even if they were supported, whether they actually work would remain a hit-and-miss game.