Sometimes UTF-16 is a more compact representation, sometimes UTF-8 is. It depends on the frequency distribution of characters in the document. But they have equivalent descriptive power; either can represent any sequence of Unicode characters. If nextml adopts UTF-16, be aware that it can be serialised to bytes in either little-endian or big-endian order (UTF-16LE or UTF-16BE), so nextml should account for those possibilities. It should also allow for the special Byte-Order Mark character (BOM), which is used to distinguish the two.
Thanks for all the great links and references. That backs up my suspicion that supporting a diversity of encodings is a matter of less urgency than it was when XML 1.0 was born.
As for the BOM, yes, that should be key in any XML successor, as it is in XML 1.0 itself. In XML 1.0, you can tell the encoding even if it's not in the XML declaration because if not, it must either be UTF-8 (if there is no BOM), or UTF-8, UTF-16LE, UTF-16BE, etc. depending on BOM.
If it's OK to say UTF only (and we banish the standalone declaration) , then there is no need for an explicit encoding declaration beside optional BOM.
