Danke Walter, manches ist nun klarer geworden. Richtig überzeugt bin ich aber ehrlich gesagt nicht.
Vorweg: Ich weiß nicht, ob Du meine Aufzählung vielleicht ein wenig mißverstanden hast: ich habe einige Fälle aufgeführt, in denen die “Lösung” mit OSM-IDs nicht funktioniert, und wollte unvoreingenommen wissen, wie sich UUIDs in diesen Fällen nach Deiner Vorstellung schlagen - nicht im Voraus behaupten, daß diese auch nicht helfen.
Noch einmal zu einigen der numerierten Punkte:
ad 1. Was, wenn vor dem Zusammenfügen beide Ausgangswege eine uuid=* hatten? Bei Bearbeitungen mit unserem geliebten Potlatch geht unweigerlich eine verloren, bei JOSM hängt es vom Nutzer ab. Aber im Idealfall steht im neuen Objekt uuid=xxx;yyy. Dann könnte das Objekt zwar noch unter beiden UUIDs gefunden werden, aber nicht mehr per einfachem Key/Value-Vergleich, sondern man müßte schon nach Substrings suchen, bzw. bei der Overpass API per Regex.
ad 3./4. Wenn das Aufspalten grundsätzlich problematisch ist, muß der Editor eine klare Vorgehensweise beherrschen bzw. eine Handlungsempfehlung an den Nutzer geben. Wie soll diese aussehen? Ich kann mir nicht vorstellen, wie per Algorithmus auch nur einigermaßen zuverlässig entschieden werden kann, welches der Tochterobjekte nun das “bedeutsame” ist, welches die UUID behalten soll.
Meines Erachtens steht schon die Verwendung von UUIDs in OSM (mit seiner Arbeitsweise) im Widerspruch zum UUID-Konzept. UUIDs sollen eindeutig sein, daher werden sie (in anderem Zusammenhang) für jedes Objekt automatisch vergeben, und zwar so, daß zwei Objekte (praktisch) nie dieselbe UUID bekommen. Tags in OSM sind im allgemeinen nicht eindeutig (etwa name=Bahnhofstraße); und selbst wenn man initial eindeutige Werte vergibt, kann (lies: wird) etwa durch Kopieren von Objekten oder Merkmalen sowie Aufspalten von Wegen die Eindeutigkeit verloren gehen. Die schon genannten AND_nosr_r-Tags (sowie AND_nosr_p und AND_nodes) waren ursprünglich wohl mal dazu gedacht, ein Import-Update durchführen zu können. Es gab sicher auch noch andere Gründe, warum es dazu nie gekommen ist, aber den Objekten mit diesen Tags sind genau die oben aufgeführten Bearbeitungen widerfahren, die sie zur Identifizierung unbrauchbar gemacht haben.
Ein weiteres Problem hast Du schon selbst angesprochen: kryptische Tags. Den zur eindeutigen Identifizierung gedachten Tags von AND, TMC, openGeoDB et al. ist gemein, daß “der normale Mapper” sie nicht versteht (bzw. mangels Dokumentation nicht einmal eine Chance dazu hat). Eine bessere Dokumentation wäre zwar möglich, dennoch würde es UUIDs m.E. ähnlich ergehen. Selbst ein fortgeschrittener “normaler Mapper” (ganz zu schweigen von einem Anfänger) braucht sie in der Regel nicht, noch dazu sind UUIDs nicht unbedingt ein intuitives Alltagskonzept, das jeder sofort versteht. Also würden sie bei Bearbeitungen einfach links liegen gelassen, was genau falsch sein kann. Oder gelöscht, was (außer nach dem Kopieren) immer falsch ist.
Allerdings sehe ich auch keinen Weg, die Tags weniger kryptisch zu formulieren. uuid=* ist für “Uneingeweihte” unverständlich, aber mit einem furchtbar langen (dafür erklärenden) Schlüssel (“this_object_has_the_following_unique_identifier_please_edit_carefully”=*) ist niemandem gedient (würde noch nicht einmal helfen, da viele Leute bei OSM des Englischen nicht hinreichend mächtig sind). Aber auch ein Wert wie uuid=“da7b4de1-4c68-40ca-9735-53e559fcce54” sieht erst einmal wie Bitmüll aus und ist schon deswegen in Löschgefahr.
War nur von allen denkbaren Beispielen für eine komplette Umdeutung das, welches Dir am besten vertraut sein dürfte. Es wäre ja theoretisch möglich, daß die Relation vorher ebenfalls für ein “bedeutsames” Objekt stand.
