Zum anderen war das nicht auf diesen Fall bezogen., sondern allgemein. HTML5 beschreibt, wie sich ein Parser bei bestimmtem Code zu verhalten hat.  Als Webautor möchte ich aber wissen, wie mein Code überhaupt auszusehen hat.

Ich habe auch allgemein anhand eines Beispiels beantwortet.

HTML5 beschreibt, wie Code auszusehen hat. Wie kommst du darauf, dass es das nicht täte?

»If an HTML document does not start with a BOM, and if its encoding is not explicitly given by Content-Type metadata [usw. usf.] the encoding must be specified using a meta element with a charset attribute or a meta element with an http-equiv attribute in the Encoding declaration state.«
http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#charset

Hier wird normativ festgelegt, dass folgende Kodierungsangaben konform sind:
<meta charset="foo">
<meta http-equiv="Content-Type" content="text/html; charset=foo">

Als Webautor ist man mit simplen Grammatikregeln weitaus besser dran als mit ellenlagen kaum verständlichen Parsingregeln. Solche bei HTML5 durchlesen zu müssen, ist eine Zumutung.

Ich habe die Regeln für die Angabe der Zeichenkodierung in HTML5 ja verlinkt. Mein Vorschlag, schau dir den HTML5-Standard einfach mal in seinem Aufbau an, bevor du solche Urteile fällst. Es besteht ein großer Unterschied zwischen der Beschreibung der Grammatik und dem Parsing. Das sind einfach unterschiedliche Kapitel. Letzteres ist tatsächlich episch lang, braucht dich als Webautor aber nicht zu interessieren. Es gibt nur eine richtige Syntax für die HTML-Serialisierung (die, wie auch HTML 4, natürlich in einem gewissen Rahmen flexibel ist). Das Parsing hingegen unterstützt diese, aber auch andere, fehlerhafte. Konformität wird NICHT über das Parsing definiert! Es ist nicht alles konform, was parsebar ist.

Es ist bekannt, dass die HTML5-Spezifikation nicht die relative Einfachheit von HTML 4 besitzt, was die Zielgruppe der Webautoren angeht. Es ist kein Authoring Guide, sondern eine technische Spezifikation, die die genaue Funktionweise und die genauen Konformitätsregeln festlegt. Beides ist eben faktisch kompliziert (HTML5 schreibt in diesem Punkt auf, was die UAs bereits tun, und harmonisiert dieses) und kann nicht in einem Satz abgehandelt werden. Deswegen geht die für Webautoren interessante Information auch mal unter. HTML 4 ließ das alles außen vor, was lediglich dazu führte, dass sämtliche Implementierungen voneinander abwichen und Wildwuchs bei der Kodierungs-Heuristik entstand.

Prinzipiell versucht HTML5 dieses Problem zu adressieren, indem es auf W3C- und WHATWG-Seite jeweils Versionen der Spec für Webautoren gibt:
http://dev.w3.org/html5/spec-author-view/
http://developers.whatwg.org/
Wie weit diese sind, habe ich aber nicht geprüft,

<meta content=text/html; charset=utf-8 http-equiv=Content-Type>. Seit wann hat dieser fehlerhafte Code funktioniert? Wieviele Webseiten verwenden diesen fehlerhaften Code? Warum wurde an dieser Stelle eine Fehlertoleranz in Browser implementiert, die vermutlich mehr Probleme schafft als löst?

Aus Spaß haben sie es sicher nicht implementiert. Kein Software-Entwickler würde das ohne Not tun. Offenbar bestand eine Notwendigkeit dazu. Die Kausalität, die ich bereits beschrieben habe: Es gab viele Sites, die diesen Fehler gemacht haben. Und warum hat HTML5 diesen Algorithmus standardisiert? Nachdem die eigenen Untersuchungen von großen Mengen an Markup die Erfahrung der Browserhersteller bestätigt haben, dass dieser Fehler häufig ist: http://code.google.com/intl/de/webstats/2005-12/metadata.html

Insofern hätte XHTML 2, welches verarbeitbares Markup erfordert, einfach bedeutet, dass 95% der Websoftware Makulatur gewesen wären.

Nein, keinesfalls. Die Implementierung von XHTML 2 in Browser hätte nicht bedeutet, dass Browser bestehende und neue Dokumente nicht mehr als Tag-Soup verarbeiten könnten. Websoftware hätte weiterhin Tag-Soup generieren können.

Sehr richtig. Und aus dem Grund wären die meisten bei Software geblieben, die Tag-Soup produziert. Es ist ja auch viel einfacher, wenn eine Blogsoftware mit String-basierten Templates arbeitet. So kann der 08/15-Webseitenbastler mal eben im HTML-Code herumschmieren und z.B. Weatherpixie-Code in die Sidebar hineinkippen, ohne dass ihm die Site um die Ohren fliegt, weil es strenggenommen Müllcode ist.

Mathias