Steve,
I certainly agree with you that name constraints (along with policy constraints) are critically important in PKIs that make extensive use of cross certification. The U.S. Government's Federal Bridge CA (currently in a pilot stage) includes name constraints in cross certificates that it issues and I expect that CAs will do this more frequently as cross certification increases.
However, I don't agree that it's important to let end-users associate name constraints with trust anchors. Few end-users even understand what a trust anchor is. The number of end-users that could properly assign name constraints to each trust anchor is much smaller, still. When I talk with browser vendors, they say that PKI must become simpler, not harder!
A better and more practical way to achieve the same end is for the end-user to have a single trust anchor (the corporate or departmental CA) and have that CA issue cross-certificates with name constraints. This allows the administrator to manage all the name constraints (as well as policy mappings and other policy constraints, which may be necessary in a cross-certification environment).
If the user is really paranoid, they can set up their own CA and use that as their trust anchor. Anyone sophisticated enough to configure name constraints is sophisticated enough to run their own CA. And there are plenty of free CA software packages out there that are perfectly adequate for issuing a few cross-certificates with name constraints.
I certainly don't mind if son-of-2459 says implementations MAY support name constraints on trust anchors. I just don't want to have it as a SHOULD or a MUST.