Cool URIs don't change - aber was jetzt :)

[Beat]

aussehen soll das ganze später so (eine dieser varianten):

1. example.com/artikel/123
2. example.com/artikel/titel-foo-bar
3. example.com/artikel/123/titel-foo-bar
4. example.com/artikel/titel-foo-bar/123
5. example.com/artikel/123-titel-foo-bar

mit dem umschreiben per mod_rewrite habe ich kein wirkliches problem

1. hat den vorteil, dass die logik sehr einfach ist, allerdings den nachteil, dass der titel nicht in der adresszeile ersichtlich ist - aus gründen der suchmaschinenfreundlichkeit ist das aber ein vorteil - ebenso ist es für einen normalen menschen einfacher einen artikel wiederzufinden (suche in der history zb)

Ehrlich gesagt halte ich nicht viel davon.
Ein Anwender sieht in den Bookmarks eher den Inhalt des title Elements. Er hat zudem noch andere Instrumente, neben welchen dein Anliegen für die Bookmarks irrekevant ist.
Im Location Bar sagt mir ein sprechender Titel auch nicht viel, weil ich solche Titel nicht eintippe. Sie werden zurückgegeben und meistens nehme ich sie nicht mal zur Kenntnis.
Aus der Sicht der Suchmaschine vernichtest du Information. id=123 stellt eine Logik dar. Deine Pseudopfade hingegen nicht.
Wenn ich eine Url eintippen muss, nehme ich die copy-Paste Funktion. Muss ich das wirklich händisch machen, dann ist bei einem sprechenden Titel der Schreibfehler eher noch wahrscheinlicher als bei einer vierstelligen Zahl.

Aber man kann auch das Prinzip automatischer anonymer SeitenIDs hinterfragen. Warum ist ein CMS nicht in der Lage, sprechende Seiten-IDs zu erzeugen, und Duplikate zu vermeiden, indem es vom Erzeuger die Angabe eines Identifikators verlangt? Schliesslich ist eine Seite ein Patch von kleinen Files, und das ganze stellt doch irgendwo ein zentrales Moment der Seiten-Erzeugung dar, dass man einen Seiten-Identifikator nebst einem Seitenlabel bestimmt. Zumindest handhabe ich es so im CMS das ich derzeit entwickle.
Analogie:
Ein User im Accountsystem hat ja auch einen einmaligen Namen (hoffentlich)[1] , derweil eine UserId als aussageloser Hash existiert, um den User mit seinen Rechten mit anderen Daten zu verbinden. Aber das wesentliche ist die Definition des Usernamens bei der Erstellung des Accounts.

[1] Ich will nicht das Risiko eingehen, dass zwei Personen sich mit gleichem Namen und Passwort anmelden. Das erlaubt mir aber nicht, dass der User den Namen 123 zu akzeptieren hätte, nur weil ich das schnell automatisch produzieren kann.

mfg Beat