Im Moment wäre es nur eine Heuristik. Aber man könnte das ja durchaus auch als feste Regel dokumentieren: “Wenn nicht durch eine Relation anders angegeben, beziehen sich Tags wie support=street_lamp immer aufs nächstgelegene Objekt dieser Art.”
Solche Regeln, dass Relationen zwar existieren, aber in der großen Zahl der Fälle nicht nötig sind, gibt es ja schon einige. Zum Beispiel wird die building-Relation nur dann benötigt, wenn die einfache Regel, dass ein Gebäudeteil zum umschließenden Gebäude-Umriss gehört, nicht anwendbar ist. Abbiegebeschränkungs-Relationen sollen nur gemappt werden, wenn sie nicht schon aus Einbahnstraßeregelungen o.ä. hervorgehen. Ähnlich bei Bridge-Relationen vs. man_made=bridge-Flächen etc.
Ob 1:1 oder 1:n macht für mich nicht den großen Unterschied, beides ist bei mir recht einfach auswertbar. (Aber meine Architektur ist verglichen mit anderen Renderern im OSM-Ökosystem eher ungewöhnlich, von daher ist die Aussage nicht unbedingt auf andere Datennutzer übertragbar.)
Was viele Auswerter hingegen etwas stören dürfte, ist das Konzept als solches: Dass ein Objekt, das eigentlich ein Node sein sollte, in Ausnahmefällen stattdessen eine Relation ist – nur weil ein anderes Objekt an derselben Stelle liegt. Für die allermeisten Anwendungsfälle wäre es viel bequemer, zwei Nodes zu haben, die mit einer Relation verbunden sind. Dann könnte nämlich die große Mehrheit der eher einfach gestrickten Auswerter die Nodes ganz normal nutzen, ohne die Relation überhaupt zu beachten.
Generell bin ich (wie dieterdreist ja schon angemerkt hat) nicht überzeugt von der node-Relation. Aus meiner Sicht vermischt sie zwei grundverschiedene Ziele: 1. auszudrücken, dass ein Objekt an einem anderen befestigt ist und 2. zu vermeiden, dass zwei Nodes an derselben Stelle liegen.
Ich würde den Verkehrsspiegel im Ausgangsbeispiel vermutlich ohnehin ein bisschen neben den Laternenmast setzen, eben auf der Seite wo er auch in der Realität ist. Aber wenn jemand zwei Nodes auf exakt dieselbe Position legen möchte, dann ist es m.E. deutlich intuitiver, genau das zu tun: Zwei Nodes auf dieselbe Position legen, statt auf einmal zu Relationen zu greifen.
Das Ziel #1 hingegen finde ich prinzipiell sinnvoll für Fälle, wo ein support-Tag nicht reicht. Aber für mich ist das gar nicht auf Nodes beschränkt – es könnte ja auch z.B. ein Briefkasten an einem Zaun oder einer Gebäudewand befestigt sein, also einer Linie oder Fläche. Daher wäre mein Vorschlag eine attached_to-Relation: Die aneinander befestigten Objekte könnten ganz normal gemappt werden, also als Node, Linie oder Fläche, und dazu kommt eine Relation, die die beiden Objekte als Mitglieder hat.