Bitcoin, Ethereum und XRPL haben heute alle Spezifikationen nachgebessert, die laengst ausgeliefert waren
Drei Oekosysteme, drei Repositorien und heute in allen dieselbe Art von Aenderung: eine geschriebene Spezifikation, die von dem korrigiert wird, was aus ihr gebaut wurde.
BIP-138 ist das klarste Beispiel. Ein eingeflossener Pull Request aendert die Empfaengermenge des Wallet-Backup-Verfahrens von den Schluesseln im Deskriptor oder in der Wallet-Policy hin zu den eindeutigen oeffentlichen Schluesseln ueber alle Deskriptor- und Policy-Mengen und alle Inhaltselemente der Nutzlast. Das ist eine andere Ableitung. Backups nach der alten Lesart lassen sich unter der neuen nicht reproduzieren, und der Anlass war, dass eine Nutzlast mehr enthielt, als die urspruengliche Formulierung bedacht hatte.
EIP-8298 streicht das Wort "runtime-only" aus der Beschreibung von SETCODEFROM, und der Commit-Titel sagt den Rest: im Initcode erlauben, als Quelle ein Konto mit bereits bereitgestelltem Code verlangen. Die Implementierung hat gezeigt, dass die Beschraenkung an der falschen Stelle stand, und der Vorschlag ist nachgezogen.
Im Repository der XRPL-Standards tun das fuenf offene Aenderungen ausdruecklich — XLS-86 und XLS-78 an ihre Referenzimplementierungen angeglichen, die Vault-Bedingungen in XLS-65 zweimal aktualisiert, XLS-0085 mit einem dokumentierten Fehlercode von tecFROZEN auf tecLOCKED, damit er dem entspricht, was das Netz zurueckgibt, XLS-102 mit festgelegter Bytereihenfolge.

Was das bedeutet
Die zuversichtliche Lesart ist, dass alle drei das oeffentlich tun. Eine Abweichung zwischen veroeffentlichter Tabelle und laufendem Netz ist fuer Integratoren eine echte Gefahr, und das Einzige, was schlimmer ist, als eine zu finden, ist, sie in einem Repository zu finden, das die Korrektur nicht festhaelt.
Die praktische Lesart ist schaerfer. In allen drei Faellen gilt, solange die Aenderung offen ist: Massgeblich ist die Implementierung, nicht das Dokument — und Integrationscode wird fast immer gegen das Dokument geschrieben. Der Fehlercode aus XLS-0085 zeigt es am deutlichsten: Ein Client, der auf tecFROZEN verzweigt, behandelt einen Fall, den das Netz nie erzeugt, und besteht dabei jeden Test, der aus derselben Quelle stammt. Wer heute gegen einen Standardentwurf baut, sollte sich angewoehnen, die Spezifikation gegen beobachtetes Verhalten zu diffen, bevor er einem von beiden traut — und "eingeflossen" statt "veroeffentlicht" als den Punkt zu nehmen, ab dem sich eine Tabelle fest verdrahten laesst.