Vielen Dank für die Rückmeldung. Die Punkte a) bis d) bieten eine gute Grundlage, mein Verständnis darzulegen.

Zu a): Kein physisch-existentes Feature – daher kein Hinderungsgrund/keine Voraussetzung für einen Merge (Zusammenlegung). Wert ist nach einem Merge ggf. anpassbar.
Zu b) & c): Physisch-existent und zutreffend – also relevante Merkmale.
Zu d): Nicht relevant für den Merge, da Namen keine physischen Features sind (sie sind bspw. durch Tags wie "bridge:name=*", "alt_name=*" etc. abbildbar).

Nach meinem Verständnis bedeutet "One feature, one OSM element": 
Ein physisch-existentes Objekt (Feature) soll durch genau ein OSM-Element abgebildet werden. Hier ist es der Eiserne Steg.

Es lagen zwei Brückenobjekte vor (beide "way"), mit identischen Tags zu Struktur, Layer, Beleuchtung und Namen. Weitere Tags sowie vier Relationen kamen jeweils nur einmal vor. Es gab keine widersprüchlichen oder fehlerhaften Tags. Somit war der Merge auch geboten.

Meine Schritte:

- Tags beider Objekte checken: Welche Tags sind physisch-existent, welche nicht; Welche Tags sind doppelt; Verträglichkeit der Tags nach einem Merge usw. 
- Merge durchgeführt
- JOSM-Prüfung: fehlerfrei
- Osmose: keine Warnung
- Test Rendering und Routing: wie erwartet, siehe vorheriger Kommentar

Zur Frage nach "man_made=bridge" + "highway=pedestrian": Beide Tags waren bereits vorhanden und die Kombi ist durch den Merge entstanden. Es liegt keine "Sonderregel" zugrunde. Ob ggf. "highway=footway" auch funktioniert habe ich nicht geprüft.

Zur Aussage, dass "bei jeder anderen Situation" Brücke und Weg getrennt werden müssten: 
Das trifft nur auf b) und c) zu, nicht auf a) und d) weil a) + d) physisch nicht existent. Dann alternative Modellierung.

Alternative Modellierung: Möglich wäre auch die Abbildung eines einzigen Brückenobjektes als Relation mit mehreren Kind-Elementen ( https://wiki.openstreetmap.org/wiki/Key:bridge#Bridges_with_several_roads/ways_or_additional_features ). In diesem Fall erscheint dies aber nicht notwendig, da die aktuelle Umsetzung funktioniert.

Zur Konsistenz:
Die Regel "One feature, one OSM element" ist offiziell dokumentiert und bildet daher den Maßstab für Konsistenz – unabhängig von verbreiteter Praxis. Mehrfacheinträge physisch-existenter Objekte erhöhen den Pflegeaufwand und führen zu Fehleranfälligkeit. Jedes Duplikat-Feature (wie z.B. hier das doppelte Brückenobjekt Eiserner Steg) enthält zwangsläufig physisch-existente Tags und widerspricht somit dem Wiki.

Fazit:
Zwei Brückenobjekte für den Eisernen Steg sind gemäß https://wiki.openstreetmap.org/wiki/One_feature,_one_OSM_element und https://wiki.openstreetmap.org/wiki/Key:bridge nicht regelkonform. Mein Merge war ein Schritt zur korrekteren Umsetzung. Optimierungspotenzial besteht ggf. weiterhin – doch aus meiner Sicht entspricht der aktuelle Stand dem OSM-Wiki besser als zuvor.
