MCP ignoriert wichtige Lehren aus Jahrzehnten verteilter Systeme
(medium.com/@julsimon)- MCP (Model Context Protocol) wirbt mit der Standardisierung der KI-Toolintegration, ignoriert aber die in 40 Jahren aufgebauten Best Practices verteilter Systeme und von RPC.
- Dadurch fehlen in Enterprise-Umgebungen zentrale Fähigkeiten wie Betriebssicherheit, Typensicherheit, Sicherheit, Observability und Kostenmanagement.
- MCP stützt sich dabei darauf, dass diese Grundfunktionen von externen Bibliotheken bereitgestellt werden, verursacht jedoch Protokoll-Fragmentierung, Integrationskomplexität sowie zusätzliche Audit- und Sicherheitslast.
- Anforderungen wie verteiltes Tracing, Schemaversionierung, Service Discovery, Leistungsoptimierung und weitere sind weiterhin unzureichend.
- Eine frühe Einführung von MCP birgt im KI-Boom die Gefahr schwerer Störungen in Unternehmen, erhöhten Betriebsrisiken, doppelter Entwicklung und unnötigen Kosten.
Die Risiken der Einfachheit von MCP
MCP (Model Context Protocol) wirbt mit der Integration von KI-Tools als „USB-C im KI-Bereich“ und hebt dabei die Einfachheit hervor, die Eintrittsbarrieren senkt. Doch genau diese Einfachheit ignoriert die über 40 Jahre gewachsenen Lehren aus verteilten Systemen, was in realen Betriebsumgebungen zu schweren Funktionsausfällen führt. Unternehmen, die MCP heute einführen, bauen im Grunde auf einer Grundlage auf, der essenzielle RPC-Systemfunktionen fehlen.
Die gefährliche Kluft zwischen Realität und Erwartung
MCP-Befürworter stellen das Protokoll als production-ready Infrastruktur vor, doch die eigentliche Designphilosophie ist auf Entwicklerkomfort ausgerichtet und weist eine geringe Betriebsrobustheit auf. KI-Tools lassen sich zwar kurzfristig verbinden, bei tatsächlichem Einsatz mit Millionen Requests im Geschäftsbetrieb zeigt sich jedoch ein gravierender Qualitätsmangel. Überzogene Markterwartungen rund um KI führen zu einer Beschleunigung der Einführung ohne architektonische Reife und damit zu einem hohen Risiko für Betriebsfehler.
Wiederkehrende Fehler aus 40 Jahren Systemgeschichte
-
UNIX RPC (1982) führte XDR (External Data Representation) und IDL (Interface Definition Language) ein, um die Datenkompatibilität zwischen heterogenen Systemen (z. B. 32-Bit-Ganzzahlen) sicherzustellen und Typkonflikte bereits zur Buildzeit aufzudecken.
MCP ignoriert diese Erfahrung und bietet nur schemafreies JSON sowie optionale Hinweise. Typfehler treten erst zur Laufzeit auf; KI kann falsche Datumswerte erzeugen, was in Bereichen wie Finanzwesen, Gesundheit oder Fertigung zu schwerwiegenden Datenkonvertierungsfehlern und Qualitätsproblemen führen kann. -
CORBA (1991) setzte auf OMG IDL, um eine einheitliche Schnittstelle über mehrere Sprachen hinweg sicherzustellen. Bei MCP wird jede Sprache separat implementiert, wodurch bei Serialisierung und Fehlerbehandlung je nach Sprache oder Bibliothek keine Konsistenz besteht und eine Integration im Albtraum-Niveau entsteht.
-
REST (2000) erreichte Skalierbarkeit und Verlässlichkeit durch eine zustandslose Architektur, verb-basierte Bedeutungsklärung sowie Cache-Header.
Bei MCP ist die Trennung zwischen stateful und stateless unklar, es fehlen Cache-Verhalten, standardisierte Anfragebedeutung und Idempotency. Server-Skalierung, Wiederholungslogik und Lastverteilung werden dadurch extrem schwierig. -
SOAP/WSDL boten maschinenlesbare Verträge, Automatisierungspotenzial und Sicherheitserweiterbarkeit.
MCP stellt nur ein einfaches JSON-Schema bereit und bietet keine maschinenlesbaren Verträge, automatische Code-Generierung, Typensicherheit oder Auditierbarkeit. OAuth 2.1 wurde erst spät nur für den HTTP-Transport ergänzt, während stdio von Umgebungsvariablen abhängt und Sicherheitskontrollen insgesamt lückenhaft bleiben. -
gRPC (2016) integriert Observability, verteiltes Tracing, bidirektionales Streaming, Deadlines und strukturierte Fehlercodes.
MCP unterstützt nur einseitiges Event-Streaming und ist für komplexe Interaktionen ineffizient. Wesentliche Bausteine wie Trace-Kontext, Deadlines und Fehlerklassifikation fehlen.
Die Gefahr der Botschaft „Verwenden Sie nur diese Bibliothek“
Auf jeden gemeldeten kritischen Fehler von MCP wird mit zusätzlichen Drittanbieter-Bibliotheken wie z. B. mcp-oauth-wrapper, mcp-tracing-extension, mcp-schema-generator reagiert. Dennoch sind genau dies die Kernfehler des Protokolls. Je mehr zentrale Funktionen nach außen ausgelagert werden, desto größer werden Fragmentierung, Inkonsistenz sowie Verantwortungsstreuung bei Wartung, Sicherheit und Integration.
In Enterprise-Umgebungen steigen innerhalb von Monaten die Lasten für Standardisierung, Audits und Integration; zugleich nehmen Entwicklertrainings und externe Abhängigkeiten in einem ungesunden Maß zu.
Zunehmend aufgesetzte Notfall-Patches
Die Version 2025–03–26 von MCP wirkt wie ein nachträglich erstelltes Patch-Set für Fehler, die erst im produktiven Betrieb sichtbar werden. OAuth, Sitzungsverwaltung, Tool-Attribute (Annotationen) und Fortschrittsmeldungen waren von Anfang an essenzielle Funktionen, wurden aber erst im Nachhinein ergänzt.
Auch die Trennung von Tool-Attributen war zu Beginn nicht vorhanden; dasselbe gilt für Sicherheitstoken. Das verweist auf ein mangelndes Grundverständnis der Enterprise-Anforderungen.
Ein Debugging-Albtraum und fehlende Betriebsnachvollziehbarkeit
In gRPC-Umgebungen ermöglicht verteiltes Tracing mit Trace-IDs schnelles und konsistentes Debugging.
MCP bietet hingegen keine korrelierende Anfrage-ID, uneinheitliche Log-Formate und verlangt eigene Implementierungen, wodurch Debugging und Fehleranalyse mehrere Tage dauern können.
Auch betriebswirtschaftlich ist eine Kosten- und Nutzungszuordnung (Header, Tokenzählung, Quotas usw.) kaum möglich. In Cloud-Umgebungen sind Grundfunktionen in MCP nicht vorhanden, wodurch die Nachverfolgung von KI-Kosten und Verantwortlichkeiten fast unmöglich wird.
Aktuell noch vorhandene zentrale Betriebsprobleme
- Die fehlende Service Discovery verhindert eine belastbare Verfügbarkeit, Multi-Region-Skalierung und unterbrechungsfreie Updates.
- Ohne Schema-Versionierung pro Tool drohen bei Tool-Updates unvorhergesehene Brüche bei allen Clients.
- Leistungsgrenzen: JSON-Overhead, fehlendes Connection Pooling, unzureichende binäre Protokolle/Kompression und prozessbasierte Kommunikation führen zu veralteten Mustern.
Schwere Risiken beim Einsatz im Enterprise
Wenn KI in Geschäftsbereiche mit echter Verantwortung für Umsatz, Sicherheit und Qualität (wie Finanzwesen, Medizin, Fertigung, Kundensupport) eintritt, steigt das Risiko der MCP-Einführung deutlich.
Statt langjährig etablierte, robuste Integrationsmuster zu nutzen, werden Sicherheits-, Audit-, Typen- und Betriebsstabilitätsanforderungen als nachträgliche Krücken angehängt.
Strategien vom Typ „schnell bauen und brechen“ im Prototyping-Stadium können bei kritischen Diensten zu fatalen Ergebnissen führen.
Verbesserungsansätze und langfristige Anforderungen
- Kurzfristig: Typensicherheit, verteiltes Tracing (korrelationsfähige IDs), Autorisierung, standardisiertes Audit-Format und unabhängige Schemaversionierung pro Tool müssen auf Protokollebene integriert sein.
- Betrieblich: Service Discovery, Connection Pools, binäre Übertragung, Deadlines sowie standardisierte Fehler- und Wiederholungsrichtlinien sind erforderlich.
- Langfristig: bidirektionales Streaming, integrierte Quoten- und Kostenverwaltung, SLA-Umsetzung und Workflow-Orchestrierung werden für den Enterprise-Einsatz benötigt.
Fazit
Die auf Einfachheit ausgelegte Architektur von MCP passt für experimentelle, kurzfristige KI-Tool-Integrationen, führt aber im Enterprise-Betrieb zu kritisch hohen Betriebsrisiken und Kosten.
Die Einführung ist durch den KI-Hype vorangetrieben, während essentielle Funktionen wie Sicherheit, Observability und Betriebsstabilität nur als spätere, behelfsmäßige Ergänzung nachgeschoben werden.
Am Ende besteht die Gefahr, dass genau die Fragmentierung und Doppelentwicklung, die das Protokoll verhindern will, auf MCP selbst wieder reproduziert werden.
Die KI-Industrie steht vor der Entscheidung, ob sie die 40-jährige Entwicklung verteilter Systeme erneut ignoriert und alte Probleme neu auflebt – oder aus der Geschichte lernt.
Bleibt es dabei, wiederholen sich fehlgeschlagene Rollouts, Sicherheitslücken und Betriebsalträume und die Kosten tragen schließlich die Unternehmen.
1 Kommentare
Hacker News Kommentar
Ich dachte bei der Betrachtung des Titels zunächst, es handele sich um eine typische Security-Show. Beim Weiterlesen wurde mir aber klar, dass der Beitrag wirklich tiefe Einsichten enthält. Besonders auffällig ist dieser Punkt: MCP ignoriert genau diese Lehren und setzt auf optional verwendbare Hinweise bei schemafreiem JSON, wobei die Typprüfung erst zur Laufzeit erfolgt oder gar nicht passiert. Erwartet ein KI-Tool zum Beispiel einen ISO-8601-Zeitstempel und erhält stattdessen einen Unix-Epoch-Wert, kann das Modell nicht sauber fehlschlagen und stattdessen irgendein Datum erzeugen. Solche Fälle können im Finanzdienst einen Trading-KI dazu bringen, Zahlen falsch zu interpretieren und Transaktionen mit falscher Dezimalpräzision auszuführen. Im Gesundheitswesen kann eine fehlerhafte Typkonvertierung von Patientendaten zu einer falschen empfohlenen Medikamentendosis führen. In der Fertigung kann in der JSON-Serialisierung die Präzision von Sensordaten verloren gehen und Qualitätsprobleme verursachen. Aus meiner täglichen Arbeit mit LLMs sehe ich, dass solche Probleme tatsächlich oft auftreten. Ich kann mir sehr gut vorstellen, dass in einem MCP-basierten System irgendwann ein großer Zwischenfall passiert, bei dem ein MCP-Server merkwürdige Daten ausgibt, ein LLM diese übernimmt und eine völlig unpassende halluzinatorische Ausgabe produziert und das anschließend zu immer größeren Problemen eskaliert. Wenn man menschliche Fehler, die fehlende Fehlerbehandlung von LLMs (Halluzinationen) und die Kultur von Startups, die neue Services übereilt veröffentlichen, kombiniert, entstehen zwangsläufig neue Fehlerarten. Und wenn das hochkocht, werden Twitter-Nutzer endlos darüber reden, dass eine AGI den nuklearen Abschusscode hackt; diese Szene wäre schon ziemlich interessant.
Ehrlich gesagt dachte ich bis 2023, dass die technischen Fehler aus Star-Trek zu fiktional wirkten, als könnten sie tatsächlich nicht passieren. Seit LLMs da sind, habe ich jedoch das Gefühl, dass das sehr wohl passieren kann. Mir ist außerdem unklar, was LLM-Integration überhaupt noch mit Engineering zu tun hat und ob es überhaupt sinnvoll ist, die gesamte Firmeninfrastruktur einer externen Kontrolle zu überlassen. Mit der mangelnden Reproduzierbarkeit dazu kann man „irgendwie wird es schon gehen“ nicht als Engineering bezeichnen.
Der Autor kritisiert Dinge, die ich nur schwer nachvollziehen kann. MCP unterstützt JSON Schema, sodass Serverantworten zwingend diesem Schema folgen müssen. Wenn ein Schema einen ISO-8601-Zeitstempel verlangt und der Server stattdessen Unix-Epoch-Werte sendet, ist das ein klarer Protokollverstoß. Der Artikel behauptet, MCP könne keine typsicheren Clients erzeugen, obwohl bereits unzählige JSON-Schema-Codegeneratoren existieren; daher ist das faktisch falsch.
PEBKAC (Bedienerfehler) gibt es ohnehin schon, LLMs automatisieren das nur auf einem anderen Niveau.
Beim Thema medizinische Telemetrie habe ich selbst erlebt, wie wichtig korrektes Time-Parsing ist. Vielleicht habe ich daher überhaupt erst angefangen, Unit Tests zu schreiben. In Situationen ohne NTP habe ich sogar den Timestamp im Header neu berechnet und korrigiert. Solche Maßnahmen waren oft aus Gründen von Incident Reviews und medizinischer Haftung notwendig. Beispielsweise kann die Differenz zwischen einer Medikamentengabe kurz vor Herzstillstand und der dokumentierten Gabe lebensentscheidend sein. Wie im aktuellen britischen Post-Office-Fall kann ein einziger Datenfehler ein Leben ruinieren, und bei medizinischen Daten können 60 Sekunden die Welt auf den Kopf stellen.
MCP hat den Zweck, Transport und Kontextmanagement zu übernehmen. Die rationale Verantwortung für Schnittstellenfunktionen wie Schemadefinition und Validierung liegt bei den Anwendern. Das ist ähnlich wie die Kritik, dass HTTP keine JSON-Validierung unterstützt – was einfach selbstverständlich ist.
MCP will als ‚USB-C der KI-Welt‘ werden. Ironischerweise ist das für mich eher ein Beleg für die Problematik von USB-C als ein Erfolg von MCP. USB-C kann fast alles verbinden, doch wegen mangelhafter Standardkonformität ist es ähnlich inkonsistent wie inkonsistentes JSON-Parsing oder Protokollabweichungen bei MCP. Wie bei den vielen unterschiedlichen USB-C-Kabeln wirkt es auf den ersten Blick universell, während die Realität sehr viel komplexer ist. Ich glaube, klar getrennte APIs oder Protokolle wären sinnvoller.
Das extremste Beispiel für das Scheitern von USB-C ist für mich Apples Entscheidung, beim neuesten M4 Mac mini die USB-A-Ports zu entfernen. Obwohl der Stecker gleich aussieht, liefern optisch identische Ports tatsächlich völlig unterschiedliche Leistung, und Nutzer lernen das oft erst später nach der Veröffentlichung. Früher konnte man bei Apple-Silicon-Desktops und -Laptops davon ausgehen, dass jeder USB-C-Port 40 Gbps Thunderbolt bot; jetzt sind manche nur USB3 mit 10 Gbps. Ob es 10 oder 40 Gbps sind, erkennt man nur aus dem Datenblatt oder einem kleinen Icon. Hätte Apple ein paar USB-A-Ports beibehalten, wäre die 10-Gbps-Grenze sofort klar sichtbar gewesen, stattdessen wurde der Markenwert von USB-C eher verwässert. Letztlich landen sogar die meisten USB-C-Geräte über Adapter bei USB-A, und USB-C-Versionen sind teurer, seltener und oft qualitativ schlechter. Aber es ist eine Welt, in der Hype und Fandom über Nützlichkeit und Bedienbarkeit siegen.
Bei der Aussage ‚USB-C: universell, aber intransparent‘ musste ich schmunzeln. Ich nenne das gelingend erreicht.
Bei SOAP gibt es die Bewertung „zu langatmig, aber es versteht etwas, das MCP nicht kennt“. Die Realität ist: Ich glaube nicht, dass damals jemand SOAP wirklich verstanden hat. Ich pflege heute noch Legacy-SOAP-Systeme, und ich habe nicht ein einziges positives Wort für SOAP zu verlieren. Für niemanden kann es als Vorbild dienen.
Tatsächlich war SOAP ein riesiges Desaster. Dass eine eigentlich einfache Idee so unnötig komplex gemacht wurde, ist kaum zu glauben. XML war selbst schon komplex, dazu kamen vage Definitionen von WSDL oder Multi-HTTP-Parts, plus mangelnde Sprachinteroperabilität (z. B. SOAP-Erfahrungen mit .NET-Servern und Java-Clients). Wenn ein Trend vorbeigeht, erinnern sich Leute nur noch an die guten Teile, aber ich würde persönlich lieber einen Monat SOAP verwenden, als 50 Jahre lang schemafreie JSON-API-Entwicklung zu machen. Ich halte protobuf und capnp für deutlich besser.
REST (faktisch oft JSON-RPC) und GraphQL versuchen noch immer, das abzubilden, was SOAP und SOA boten. Ich finde es schmerzhaft, dass bei jeder neuen Technologie automatisch alles Gute über Bord geworfen wird.
Protokolle mit dem Wort „Simple“ im Namen waren nie wirklich simpel. Ich habe das Gefühl, wir werden bald ein Protokoll wie SMCP sehen.
Es gibt einen lustigen und treffenden SOAP-Artikel hier, den ich teilen möchte: https://harmful.cat-v.org/software/xml/soap/simple. Ich mag XML-basierte Technologien generell, und speziell die Typkomposition und Validierungsmöglichkeiten von XML Schema sind für mich nach wie vor einzigartig. Aber SOAP fühlt sich wie ein unnötig großer Koloss an. Was als einfache Remote-Call-Spezifikation begann, wurde zu einer Spezifikation, die alles definieren wollte und am Ende selbst nicht richtig funktionierte. SOAP verspricht Unterstützung für viele Transportprotokolle (sogar SOAP over email), diverse RPC-Formen, UDDI und sogar eigene technische RPCs – in der Praxis liegen jedoch zentrale Implementierungen wie Authentifizierung, Caching oder HTTP-Response-Codes beim Nutzer.
Ironischerweise war es genau diese SOAP-Vorführung damals, die mich dazu gebracht hat, SOAP dauerhaft abzulehnen. Innerhalb derselben Sprache funktionierte es halbwegs, sobald verschiedene Sprachen ins Spiel kamen, war es katastrophal. Ich denke, genau deswegen mochte Microsoft SOAP derart.
CORBA entstand 1991 mit der Einsicht, dass in heterogenen Umgebungen nicht einfach nur für jede Sprache nur das Protokoll implementiert werden darf; OMG IDL erzeugte in mehreren Sprachen konsistente Bindings und verhinderte auf diese Weise Interface-Konsistenz- und Serialisierungsprobleme. Das ist richtig, aber ich bezweifle, dass es ein echter Erfolg war.
Die heutige JSON-zentrierte API-Welt ist als Reaktion auf die Fehlschläge von CORBA und SOAP zu sehen. Ich glaube nicht, dass man die Lehren von CORBA vergessen hat; eher wurden sie bewusst verworfen.
Ich habe an einem Ort gearbeitet, an dem CORBA extrem gut eingesetzt wurde. Vermutlich lag der Erfolg daran, dass es dort Senior-Ingenieure mit starker CORBA-Expertise gab.
1998 bewarb ich mich bei AT&T für eine Position mit CORBA, und das war meine letzte CORBA-Erfahrung (danach habe ich es nur noch als „Download verzögern“ im JDK-Umfeld gesehen). Der Interviewer gefiel mein konkurrierendes Code-Beispiel nicht, obwohl die Alternative zwar Race-Conditions enthielt, ich es aber nicht schlüssig vertreten konnte. Später stellte sich heraus, dass meine Antwort im Kontext des Java Memory Models eigentlich korrekt war.
CORBA hat vieles richtig gemacht, war aber ein Produkt der Ende-1980er-Telekommunikationslandschaft und des OOP-Hypes. Deshalb wurden Annahmen wie Netzwerktransparenz, Vertrauenswürdigkeit und Symmetrie fest verankert. In der realen Welt haben wir aber Timeouts, Retries, Netzüberlastung und Systemabstürze. Vor allem war das CORBA-C++-Binding vor STL furchtbar, während andere Sprachen besser abschnitten.
Selbst bei Projekten mit klaren technischen Stärken, aber kommerziellem Scheitern kann man diese Stärken durchaus würdigen.
In der MCP-Debatte wird der eigentlich gelernte Kern „MCP“ übersehen: Komplexität macht die Nutzung und Einführung so schwer, dass die Praxis meistens zu einfachen Ansätzen greift. Deshalb wurde JSON über HTTP zum Standard. Selbst bei großen Tech-Unternehmen dauert die Umstellung auf leistungsfähigere Serialisierungsprotokolle wie gRPC oft Jahre und kann mehrfach fehlgehen. MCPs eigentliche Rolle sehe ich in der Standardisierung einfacher JSON-API-Verträge, damit die Generierung von Tokens und Tool-Call-Stilen für LLMs leichter fällt.
MCP ist nicht perfekt, hat aber die wichtigste Lehre aus Jahrzehnten RPC-Geschichte verinnerlicht: Die Einführung und Nutzung von zu vielen Features wird am schwierigsten gemacht. (Ähnlich wie der Aufstieg von JSON gegenüber XML.) SOAP war für Systeminteroperabilität zu komplex, XML samt Schema zu umständlich. CORBA war wegen komplexer Libraries/Frameworks in damaligen modernen Sprachen verhasst. gRPC ist schnell, aber schwer lesbar und erfordert aufwendiges Mapping. Der Kern heutiger RPCs ist REST und JSON. Die genannten Standards sind verdrängt oder gRPC ist auf extremen High-Performance-Einsatzbereich beschränkt. Dass REST und JSON der Hauptstrom wurden, liegt genau an diesem Siegeszug der Einfachheit; MCP ist genau dafür ausgelegt.
Viele gute Beiträge. Wir scheinen MCP falsch zu verstehen. Das eigentlich Wichtige ist, dass es in der gesamten Industrie ein Missverständnis darüber gibt, was Agenten sind und wohin sie sich entwickeln. Viele Webplattformen glauben, dass Agents fest in der verteilten Netzwerk-Infrastruktur verankert werden und versuchen, alle Agents im Container per MCP an einen Service Mesh anzubinden. Ich meine, den Ansatz „web-native Agents sowie SDK/Frameworks sollten wie Server-Anwendungen deployed werden“ für falsch zu halten ist – das sind keine Agents und nicht einmal die frühe Evolutionsstufe. Ein echter Agent-Harness wird nur von wenigen Providern wie Frontier Labs gebaut werden können und sich in Richtung Personalization entwickeln (z. B. ein einzelner MCP-Server für Claude Desktop auf meinem Rechner). MCP-Server sind für genau diese Single-Instance- und Harness-Szenarien gedacht.
Es wäre hilfreich, wenn jemand klar erklären könnte, warum MCP neben Swagger oder proto gebraucht wird.
OpenAPI (Swagger) oder Proto (protobuf) decken nicht alle Rollen ab, die MCP hat. Theoretisch könnte MCP auf beiden aufgesetzt werden, aber in lokalen MCP-Fällen passen die Kommunikationsannahmen von Swagger nicht, und protobuf enthält kein Kommunikationsprotokoll, daher braucht es zusätzliche Architektur. Auch wenn man JSON-RPC ersetzt, müsste man fast die gesamte MCP-Spezifikation beibehalten, was es eher komplexer macht.
MCP ist eine neue Technologie.
MCP unterstützt Streaming-Antworten. Polling oder Session-State kann man zwar implementieren, aber das bleibt ein ineffizienter Workaround.
Als OpenAI im letzten Monat für API-Nutzung 50.000 US-Dollar berechnet hat, war unklar, welches MCP-Tool im jeweiligen Team diese Kosten ausgelöst hat, welcher einzelne Tool-Call, welcher Nutzer oder welches Use Case beteiligt war. Bei den meisten KI-Technologien kommt es vor, dass die Branche den Problemen hinterher erst hinterherkommt. Aber wie bei Web-Frameworks oder Blockchain gilt es: Wenn Technologien groß werden, kann man sie am Anfang nicht vollständig verstehen. Die Lücken schließen sich mit der Zeit. Bei KI stimme ich zu, dass wir weiter Ideen und Aufmerksamkeit teilen sollten. Es ist wirklich eine spannende Zeit.
Wenn es um die Wahl zwischen besserem Design und „good enough“ geht, gewinnt am Ende oft „good enough“. Beispiele dafür: Multics vs. Unix, XML-basiertes SOAP vs. JSON-basiertes REST, das Scheitern von XHTML, JavaScript selbst und viele weitere. Deshalb nehme ich an, dass Menschen immer wieder „good enough“ neu implementieren, Probleme erst dann durch temporäre Pflaster beheben und dann weiterleben.
Das ist die bekannte Wiederholung des Worse-is-better-Phänomens (https://en.m.wikipedia.org/wiki/Worse_is_better). Es wurde über die Zeit immer wieder bestätigt. Ich neige selbst immer wieder zu „besser“ als zum „gut genug“, aber die Realität ist eben nicht immer so.
Für xforms 2.0 bräuchten wir eine Minute Schweigen. Eine Welt, in der wir leben könnten: funktionierende Web-Formularvalidierung, Microdata...