* According to HTML5,  HTML-parsers must as minimum support UTF-8
    and Windows-1252.
   http://dev.w3.org/html5/spec/parsing.html#character-encodings-0
* While according to XML, XML-parsers must as mininum support UTF-8
   and UTF-16.
* Polyglot Markup, though, "prefers" UTF-8 (based on HTML5's UTF-8
   preference, one should think), but else follows the XML approach and 
   permits both UTF-8 or UTF-16.

AS A RESULT, it becomes possible to author "polyglot markup" that works fine in XML-parsers, but which isn't required to work in all and any HTML-parser.

We should not declare mark-up that isn't required to work in a HTML-parser as "polyglot markup". Hence we should conclude that UTF-16 should not be a recommended encoding for Polyglot Markup.

   Discussion:

* It was suggested early on, e.g. by e.g. Sam Ruby, that UTF-8 should be the only recommended encoding for polyglot markup. And this can be a very useful suggestion. For instance, it would become a very useful way to "force" many HTML editing programs to default to UTF-8, one should think. It also meets HTML5 which says that new documents SHOULD default to UTF-8.

* However, the problem is to justify *exclusion* of UTF-16 by inference from the specs. Because, the use of UTF-16 does not seem to break with the principles behind Polyglot Markup, as laid out in its introduction:
   http://dev.w3.org/html5/html-xhtml-author-guide/html-xhtml-authoring-guide.html#introduction

* Permission to use UTF-16 in polyglot markup is logical, for instance because

   - UTF-16 can be reliably detected via the BOM, in both XMLand HTML5
  -  though HTML5 says that, quote: "Using non-UTF-8 encodings can 
      have unexpected results on form submission and URL encodings,  
      which use the document's character encoding by default", the use of 
      non-UTF-8 probably creates form problems in XML-on-the-web
      too. Thus XML and HTML are probaly in same boat here - and 
      hence it does not seem logical to use against UTF-16 that some 
      form submission problems could occur.

* That said, the problems with non-UTF-8 *should* carry *some* 
    weight: e.g. those form submission problems could cause greater 
    problems in XML and it is a small irriation that it is not permitted/
    possible to use an  explicit character declaration in UTF-16 encoded
    documents.

However, the fact that HTML-parsers aren't required to support UTF-16, is a more fundamental nail in the coffin.  

Can it have any real-world effect? Not so much when it comes to "big" browsers - they support multiple encodings. But for "simpllistic" parsers of differnent kinds, it could probably have an effect.