Ryan: I think the history lesson is that prohibiting PrintableString turned out to be a bad idea, hence the reversal of that prohibition in RFC5280. If you believe that the world has since moved on and is now ready to prohibit PrintableString (for DirectoryString attribute types), then I think a 5280-bis effort would be the way forward.
I take your point about multiple options, but...
PrintableString is much simpler than UTF8String. Validating whether or not a string contains only characters permitted by the PrintableString character set is not rocket science. Validating the same for UTF8String is harder. If a CA can make a mistake when encoding a PrintableString, what makes you believe that they won't make a mistake when encoding a UTF8String?
Some DN attributes (serialNumber, countryName, joiCountryName) can only be encoded as PrintableString, so many CAs are going to have to deal with this ASN.1 type anyway.
If you were to add new rules (to the BRs, or to the Mozilla and/or Chrome root store policies) to prohibit PrintableString for certain attribute types where RFC5280 permits it, you would further complicate the requirements placed on CAs. The more rules there are, the harder it is to keep them all. The more documents a CA representative has to look at to derive the effective rule set (X.520, RFC3280, RFC5280, BRs, Mozilla/Chrome root store policies) for a particular DN attribute, the more likely it is that their head will explode.
I'm sure nobody cares about Win9x any more. It's the unknown unknowns I'm concerned about though. Many certs we issue use only PrintableStrings. Can you guarantee that all of our customers use their certificates only with software that supports UTF8String?