Meine Herren!

Mit der selben Syntax, können wir auch tiefer verschachtelte Zusammenhänge ausdrücken:

<input name="person[adresse][plz]">

Klar kannst Du das auch so ausdrücken.

Und das hat einen entscheidenden Vorteil gegenüber deiner Idee: Man bleibt kompatibel zur Standard-Verhaltensweise von Formularen, die ganz gewöhnlich abgesendet werden. Es ist weder clientseitig noch serverseitig irgend eine Extra-Behandlung notwendig.

Indes: "person[adresse][plz]" ist und bleibt ein String, eine Sequenz. Egal ob GET oder POST übertragen wird stets:

key=value ; aneinandergereiht...

wobei das array auch nur dann erst beim Parser entsteht, wenn der entsprechend programmiert ist.

Jein. Ich glaube hier liegt ein Schlüssel vergraben, um das komplexe Zusammenspiel der Akteure zu verstehen. Deshalb möchte ich hier noch weiter ins Detail gehen:

person[adresse][plz] ist ein Identifikator. Mit ihm soll eine Eigenschaft assoziert werden. In dieser Form lässt er sich als Pfad auffassen. Das Konzept von Pfaden findet in der IT immer wieder Anwendung. Zum Beispiel bei Verzeichnispfaden: person/adresse/plz oder als Zugriffsmechanismus in JavaScript: person.adresse.plz. Das Konzept ist einfach zu begreifen.

Wenn wir irgendwo einen HTML-Quelltext lesen und dort steht [code lang=html]<input name="person[adresse][plz]" value="1234">

  
Das Prinzip ist aber nicht nur vom Menschen leicht zu verstehen, es ist auch auf Computern leicht zu implementieren. Wie eben gesehen ist das Prinzip sehr abstrakt, und das können wir uns selbst in diesem simplen Formular-Beispiel sehr zu Nutze machen. JSON kennt zum Beispiel auch das Konzept von hierarchischen Daten. Wir können den Pfad person[adresse][plz] auch als Pfad auf folgendere JSON-Struktur interpretieren:  
  
~~~javascript
{  
   "person" : {  
      "adresse" : {  
         "plz" : "1234"  
      }  
   }  
}

Und genau das wird (in Zukunft) auch gemacht, wenn wir ein Formular mit dem MIMEType application/json verschicken. Andererseits gibt es MIMETypes, insbsesondere application/x-www-form-urlencoded, die das Konzept von hierarchischen Daten nicht kennen. Das ist der Punkt, an dem du sagst: am Ende ist es nur eine perfide Sequenz von Schlüssel-Wert-Zuweisungen. Und wenn man sich den Request-Body einer solchen Anfrage anschaut, dann hast du sogar Recht. ABER das spielt keine Rolle, in anderem Kontext, nehmen wir diesmal PHP, kann es wieder das Konzept von hierarchischen Daten geben. Und das ist genau der Punkt, an dem eine PHP-Umgegung sich sagt "Moment mal, diese Formular-Daten, kann ich aber schöner aufbereiten". Und genau das macht PHP und es parst die Daten in das $_POST-Array. Und dort können wir wieder mit dem nun altbekannten Konzept des Pfades, die Eigenschaft einfach auslesen: $_POST['person']['adresse']['plz'].

Diese beiden Fälle sind offenbar sehr unterschiedlich, aber wir mussten an keiner Stelle eine Sonderbehandlung entwickeln. Hierarchische Daten und Pfade um einzelne Elemente darin zu identifizieren sind ein so abstraktes Konzept, dass es auf beide Fälle anwendbar war, die zunächst mal nur wenig Gemeinsamkeiten erkennen ließen.

Letztendlich ist auch JSON genau derselbe Ansatz wie derjenige, den ich verfolge.

Nein, du wählst einen spezialisierten Ansatz, der nicht verträglich mit bestehenden Konzepten und Denkweisen ist. Es muss ensteht für den Entwickler ein echter Mehraufwand, aber ohne dabei einen qualitativen Mehrwert zu Leisten.

Und ich erzeuge auch nur Sequenzen, jedoch nicht mit textlichen Mitteln strukturiert, sondern auf Byte-Ebene

Das ist eine weitere Spezialisierung, die du vornimmst und die hier keinen effektiven Mehrwert erzeugt. Mit dem Ansatz, den ich hier bewerbe, kannst du völlig agnostisch davon arbeiten, ob die Daten textlich oder binär weiterverarbeitet werden. Diese Verantwortlichkeit bleibt ganz alleine bei dem Kodierungs-Algorithmus liegen. Das nennt sich Seperation of Concerns.

Interessant wird eine Low-Level-Serialisierung

Du bist nicht Low-Level. Du argumentierst ja gerade für eine höhere Software-Schicht, ich argumentiere dagegen.

das ist CPU- und RAM-gefällig und verzichtet auf temporäre Dateien (Siehe auch meine diesbez. Sicherheitsbetrachtungen).

Mit solchen Performanz-Aussagen musst du vorsichtig sein, hast du Benchmarks oder theoretische Erörterungen darüber, die dir das bescheinigen? Außerdem ist Performanz häufig ein Ziel, das im Widerspruch zu einer guten Software-Architektur steht. Deswegen ist es häufig so, dass man Leistungs-Optimierung nicht auf Verdacht betreibt, sondern indem man die Software auf Flaschenhälse analysiert und dann zielgerichtet optimiert, wo Bedarf besteht.

Des Weiteren benötigen Binärsequenzen weniger Bandbreite als vergleichbare Datenmengen die mit textlichen Mitteln strukturiert sind.

Wie gesagt, das ist kein exklusiver Vorteil von deinem Lösungsansatz. Das haben wir schon alles umsonst, wenn wir einfach so wenig wie möglich machen.

Es ist nie zu spät über neue Techniken nachzudenken, sich darüber auszutauschen und auch mal was Neues auszuprobieren.

Das sage ich auch nicht, ich demonstriere gerade glaube ich sehr genau das Gegenteil, indem ich mich hier mit dir austausche ;)