The key role here is the clients, which do the verification of certificate chains. This is also describe in RFC5280.
It would have been possible for us to issue a new intermediate with the same Subject, but without the nameConstraints extension. However, this would have run into nasty path building problems, where operating systems can choose arbitrarily which certificate to use if both are cached. This is a particularly bad type of deployment problem, because it leads to "works for me" on clean machines, but will fail for people on other machines, based solely on the history of other sites they've visited.
Note that we don't expect most people to reissue their certificates early. If you've been getting along fine without XP support so far, there's no need to switch. But hopefully this will allow some sites that require XP support to deploy HTTPS.
That's correct. We're deprecating the X1 intermediate in favor of X3. This isn't based on the number of HSMs (one HSM can have multiple keys active), but is based on maintaining operational simplicity.