Für mich sind es zwei Versionen desselben Dokuments.
Und hier liegt doch schon der erste Knackpunkt.
Definiere doch bitte mal "Versionen desselben Dokuments".
Unterschiedliche Versionen_eines_Dokuments kann es doch bei dem derzeitigen Konzept des Webs gar nicht geben, sondern vielmehr nur inhaltsgleiche (wenn z.B. in eine bestimmte Sprache übersetzt) Dokumente.
Dafür spricht auch

Und jedes Dokument sollte seine eigene einzigartige URL haben.
denn damit handelt es sich für mich per se schon um_unterschiedliche_Dokumente.

Das Wort 'Dokumente' ist in diesem Fall höchst unglücklich.
Ressource ist wohl das richtige Wort.
Dokumente sind Dateien, die auf einem Filesystem liegen. Sie suggerieren einen permanenten Inhalt.
Ressourcen tun das nicht.

Dadurch muss man natürlich auch individuell feststellen:

• welche Teile einer Ressource permanent sind.
• welche Teile Resultat einer Abfrage sind, die nicht in einer url repräsentiert werden können.
• welche Teile Modifikationen der Ansicht darstellen.

Wenn Abfragen im Spiel sind, haben wir immer die Qual der Wahl:
POST oder GET oder beides
POST-Abfragenzustände können (derzeit noch) nicht von Bots indexiert oder als Lesezeichen aufgenommen werden. (Google arbeitet daran.)

Die Sprache einer Ressource kann ich als Modifikation der GUI auffassen.
Eine Modifikation der GUI bedeutet aber nicht eine automatisch Modifikation der Abfrageresultate.
Strategie: die Sprache der äusseren GUI-Schale kann als GET Data vermittelt werden. Bei geeigneten Mittel als Teil des Pfades, als Query-Parameter oder als Subdomain.

Man sollte also immer eine konkrete Anwendung im Auge behalten, bevor man eine Lösung favorisiert.

Query-Strings, obwohl in Zeiten von SEO verpönt, sind

• betrieblich notwendig
• das ursprüngliche Mittel um einen modifizierbaren Aspekt einer Ressource darzustellen.

Wenn du eine komplettübersetzung einer statischen Deutschen Seite ins Englische vornimmst, so haben wir nicht einen modifizierbaren Zustand, wir haben eine redigierte eigenständige Version.
Als autonome HTML Dateien kannst du sie mit einer individuellen url im Sinne von Pfad oder Subdomain angeben.

Wenn du diese zwei Versionen dann lediglich als Datenquelle verwendest, um eine andere Ressource zu füttern,
  dann wird die Sprache der Daten im Sinne des lang Attributs repräsentiert für den angezeigten Datenabschnitt. Nun aber hat die abfragende Ressource ihre eigene url und die Sprache der äusseren GUI mag modifizierbar sein. Abragen können modifizieren, welche Sprachversionen gefiltert ausgegeben werden. Hier ist der Querystring, und GET bzw GET/POST angesagt.

Ich wollte das einfach mal so betrachten weil
SINNVOLLE MEHRSPRACHIGKEIT meist nur in hochkomplexen Netzwerken erstellt und betreut wird und im Kontext rudimentär stimmig angedeutet wird.

Meines Wissens ist die Blender Dokumentation ein gutes Beispiel davon, dass koordinierte Übersetzung oft fehl schlägt, da sich dort für englisch und deutsch zwei eigene Dokumentations-Communities gebildet haben, die nicht miteinander kommunizieren.

Andere Bereiche sind die Touristen- und Reisebranche. Sie müssen mehrsprachige GUIs vorhalten, haben aber oft mit Datenbeständen zu tun, für die keine intensive Sprachbetreuung notwenidg ist (Fahrzeiten von Zügen etc...)

Der Laie und Einzelkämpfer ist um so mehr in aller Regel ausserstande, Mehrsprachigkeit überhaupt zu betreuen, ausser in demonstrativen Versuchen oder in halbherzigen CMS GUIs.
Wo eine Website nicht mehrheitlich mehrsprachig abgebildet werden kann, macht meiner Ansicht nach language-negotiation wirklich keinen Sinn.
Für eine ausnahmsweise ordentlich übersetzte statische Seite ist das schlicht ein Overkill.
Hier ist der ausdrückliche Link zu einer anderssprachigen Version, wie du ihn in einem anderen Posting vorschlugst, die richtige Wahl.

Zum Schluss aber ein weiterer wichtiger Punkt.
Jede Datenquellenklasse, welcher möglicher Sprachversion unterliegt, braucht die Metainformation Sprache, und zwar unabhängig davon, wie die Datenquelle gespeichert wurde.
Soweit ich weiss, kümmert sich niemand darum, die Sprache zu erfassen, zu speichern, und bei abfragen und ausgaben zu berücksichtigen, in welcher Forengäste oder andere Artikelsupplier Formulare befüllen.

mfg Beat