=?UTF-8?Q?Re=3A_=5Bxml=2Ddev=5D_Should_XML_applications_follow_Postel?==

* I think Postel's principle speaks about the risk of rarely-implemented things, in particular, optional things. So I don't believe that there is any danger of a lot of XML processors that don't handle > or hex characters or CDATA sections.

* I was assuming that Postel's principle applies to implementation: minimising the use of PIs, namespaces, characters in data, are all authorial decisions. If an implementer refuses to transfer them as part of the data, their code is not "robust" it is "corrupting".  

* I don't really concur with several of your other points: indeed, I think there is a case that to get robustness you really need to only use ASCII repertoire for direct characters, and you should use HNCR for everything else.are not in the same Unicode ranges as the names in markup should be HNCR.

That being said, I think you do get a different set of "conservative" issues as soon as your XML has to be some other format at the same time as being XML: for example, that your XHTML must be text in some encoding, *AND* XML, *AND* HTML.  Or that your line-oriented XML for AWK processing must be text in some encoding *AND* simple lines *AND XML.