Bezüglich Bahnhöfen für Personen oder Güter solltest du dich mal bei der OpenRailwayMap umsehen, bevor du ein weiteres dazu nicht kompatibles Tagging-System entwickelst. Wobei mir dein Vorschlag der stufenweise Verfeinerung durchaus gefällt.
Edbert (EvanE)
Ich habe die Schlussfolgerung nicht umgekehrt. Ich schließe es aus dem Ganzen dort stehenden. Auf Deutsch würde man sagen:
Der Wartebereich der Passagiere wird als Linie oder Fläche getaggt. Wenn kein Wartebereich vorhanden ist, dann kann man einen Knoten mit public_transport=platform an die Stelle des Schildes setzen.
Dass man einen vorhandenen Wartebereich nicht als Node formulieren kann, steht im ersten und nicht im zweiten Satz.
Weide
PS: Ich hab formale Logik unterrichtet – glaub mir doch bitte, dass ich Schlussfolgerungen nicht einfach verdrehe. 
Vermutlich interepretierst du da grade deswegen vielzuviel rein.
Nach meiner OSM mapping logik wo eine node theoretisch auch mal für ein Haus stehen kann sehe ich das folgendermaßen.
Ich kann bei einer Haltestelle da wo die Leute rumstehen immer eine node setzten, egal ob das ein 0.5m breiter Bürgersteig oder eine 20m² Bushaltestelle ist. Klar sollte ich die Platform wenn möglich ausmappen, aber wenn ich grade keine Zeit, Lust oder gute Sat-Bilder habe, dann kann ich es auch erstmal bei der Node lassen.
Am Ende ist die stop_position sowieso 100x wichtiger.
Wenn Du Dich auf formale Logik berufst, solltest Du nicht mit Glauben ankommen 
Baßtölpel
Dann kennst du hoffentlich den Unterschied zwischen notwendiger und hinreichender Vorraussetzung.
Aus dem Dann (dann benutze einen Knoten) machst du ein Wenn (wenn ein Knoten) und machst die hinreichende Vorraussetzung zur Schlussfolgerung (dann darf dort nur ein Mast stehen).
Das entspricht weder der Logik (hier hinreichende Vorraussetzung) noch, was mMn schlimmer ist, der Tagging-Praxis. Viele Haltestellen sind eben nicht als Weg / Fläche erfasst sondern nur als Punkt, obwohl dort mehr als ein Mast steht.
Edbert (EvanE)
Es ist sinnlos weiter zu machen.
Weide
Moin,
An sich +1 - aber dann reicht auch ein highway=bus_stop node an der Mast-Position.
On-the-ground sehe ich nur den Mast - und der interessiert mich als Bus-Nutzer auch deutlich mehr.
Gruß
Georg
Sehe ich ganeu so. Und dann auch mit p_t=platform.
Nicht unbedingt für Fußgängerrouting
Klar “reicht” das, da public_transport=platform einfach nur der angepasste tag für das neue Schema ist, aber highway=bus_stop ist eben nicht das neue public_transport= Schema. Der Sinn von diesem ist ja grade das ganze konsistenter zu machen und alles mit diesem Tag abzudecken und nich ein highway=bus_stop, amenity=bus_station und ein railway=tram_stop zu haben.
Wenn ich eine Haltstelle habe wo Bus und Straßenbahn halten habe ich mit dem alten “system” ein railway=tram_stop und ein highway=bus_stop auf einer node, mit dem neuen einfach nur public_transport=stop_position + bus=yes + tram=yes
Das interessiert aber kein routing program. Und wie oft kommt es in der realität bitte vor, dass man an der Stelle steht wo der Bus hält, aber den Masten bzw. das Wartehäuschen nicht sehen kann? (Edit:Siehe unten)
Für mich das das vergleichbar mit dem noexit=yes tag. Ja den sehe ich nicht, aber es ist mir trotzdem wichtiger, dass der gemappt ist weil ich dann weiß, dass ich von da nicht auf den Parkplatz komme und einmal um den Block fahren muss, da interessiert es mich dann nicht ob ein paar Stellplätze vergessen wurden zu mappen.
Das war mir ehrlich gesagt noch gar nicht bewusst. Das erklärt die ganzen Wege die jemand gestern bei meiner Haltestelle eingetragen hat
Hör mir grade die ganzen alten FossGis Vortäge an… schon lustig auf was man da so stolpert… 2011:
http://ftp5.gwdg.de/pub/misc/openstreetmap/FOSSGIS2011/FOSSGIS2011-200-de-oepnv-tagging.mp4 @9:50min 
Einige werden es vielleicht gesehen haben, aber ich musste es dann doch irgendwie noch “zu Papier” bringen.
Du meinst, die 1.3 Mio Verwendungen von highway=bus_stop existieren nur, damit es auf Mapnik dargestellt wird?
Niemand hindert Dich daran, das PT Schema zu nutzen, nur solltest Du akzeptieren, dass es auch Mapper gibt die das alte System
für gut genug und vor allem für einfacher halten.
Das problem ist, dass jeder mapper noch highway=bus_stop benutzt, weil es nur dann auf der Karte gezeigt wird. Selbst wenn man 100% hinter dem neuen Schema steht setzt man das irgndwo fürs rendern rein, weil sonst kommt sowieso ein paar Tage später wer und macht es.
Ich will nicht, dass highway=bus_stop nicht gerendert wird, ich will verdammt nochmal das public_transport gerendert wird!!!
Und da wurde es schon 3 oder mehr mal eingetragen. Vor einem halben Jahr, vor ein paar Wochen und ich habs neutlich auch erst rein und keine Antwort…
Wir im deutschen Forum haben nicht viel Einfluss darauf. Wenn es dem Entwickler des Standardkartenstils nicht so wichtig erscheint wird sich daran so schnell nichts ändern. Das einzige was man noch tun könnte, wäre die nötigen Codeänderungen direkt dort zu posten, vielleicht nimmt sich dann einer der Entwickler die Zeit, diese einzupflegen.
[amenity = 'bus_stop']::amenity,
[highway = 'bus_stop']::highway {
[zoom >= 16] {
point-file: url('symbols/bus_stop_small.png');
point-placement: interior;
}
[zoom >= 17] {
point-file: url('symbols/bus_stop.p.12.png');
}
}
[railway = 'halt'],
[railway = 'tram_stop'],
[aerialway = 'station']::aerialway {
[zoom >= 13] {
point-file: url('symbols/halt.png');
}
Da geht es immer nur darum eine einzige Zeile reinzuschreiben. Die einzigen Anworten dich ich bisher gesehen habe waren das man bus/tram nicht auseinander halten kann bzw. das platform problem.
Da muss ich habe sagen nachdem ich in letzte Zeit ein duzend Haltestellen verbessert habe kann man das bei highway=bus_stop auch nicht. Das wird benutzt wie es den Leuten lieb ist.
Grundsätzlich finde ich es da auch mal angebracht nach 3 Jahren nach einer Lösung zu suchen bzw. mal zu sagen was sie wollen.
Ist grundsätzlich mal die Frage ob nicht ein “verkehrsmittel neutrales” symbol sinnvoller wäre: 
Welche genau?
Die Unterscheidung bus=yes/no oder tram=yes/no scheitert daran, dass im Standard-osm2pgsql-Stil diese Tags nicht mitgelesen werden (ich glaube, nicht mal public_transport ist da vorgesehen). Diesen Stil könnte man ändern, aber sowas macht man eher zögerlich, schliesslich schleppt man dann für alle Zeit diese Spalten mit und auf das Neu-Importieren nach einer Änderung am Stil hat man auch nicht ständig Lust.
Damit ist gemeint, dass man erst eine Relation lesen muss, bevor man weiss, was man als Icon rendern soll?
Auch das wäre ein Problem des Importprogrammes. Das kümmert sich schon um ein paar Relationen (Muoltipoygone z.B, oder Routen), um Transport hat sich da wohl noch keiner gekümmert.
Ich will nicht sagen, dass es unmöglich wäre, das alles zu erledigen, aber ein bisschen Verständnis für die Stilisten sollte man aufbringen: Es ist weder einfach, noch ist es ein Problem, das sich auf den Renderstil beschränkt. Da müsste man an mehreren Ecken viele Zeilen reinschreiben…
Grüße, Max
Naja eben einmal public_transport=platform und dann stop_postion
Glaub wirklich jemand, dass sich das nicht durchsetzt? Das das jetztige Schema nicht final ist, klar. Aber ich glaube nicht das diese ganzen tags weiterhin alle auf amenity, highway, railway etc. verteilt sein werden.
Das problem ist, dass der tag in der stop position steht, aber die meisten das Icon wohl auf die Platform haben wollen.
Ich bin da ja offen für Ideen, aber das einzige was ich mal als antwort gesehen habe ist das es schlecht ausgelegt ist, aber das hilft ja keinem beim verbessern und irgendwas bei der Datenbank, wohl was du meinst, aber war halt unverständlich.
Ich meine von mir aus kann man auch gerne noch ein (public_transport:)platform= taggen.
Ich habe zumindest arge bedenken. Es sind nur wirklich wenige Regionen, wo so ein detailliertes (um nicht kompliziert zu sagen) Schema notwendig ist. In den meisten Regionen der Welt gibt es Haltestellen, an denen Busse halten, die mit etwas Glück einen Fahrplan haben und mit noch mehr Glück diesen sogar halbwegs einhalten.
Solange das Schema keinen simplen Ersatz für die Basics hat (Bushatestelle, Busbahnhof, Bahnhof, usw.) und der komplexe Kram nur Ergänzung ist, wird sich das Schema nur da durchsetzen, wo ÖPNV sehr wichtig ist und die Mapper “Langeweile” haben.
EDIT:
Bspw. mal ins blaue geschrieben:
public_transport=stop
bus=yes
tram=yes
Damit kann der Mast beschrieben werden. Das ist simpel, für jeden verständlich und eigenständig. Dh. wenn mich die Komplexität des ÖPNV nicht wirklich interessiert, bin ich damit dann schon durch. Den Rest kann man dann, wie jetzt auch schon, hinzufügen, wie auch immer man es möchte und dann eine Relation für die Haltestelle, mit den Membern “Mast”, “Wartebereich”, “Stopposition”,…