We can sort out our differences and clarify the opposing views first, before presenting to the global audience to decide osm.wiki/User_talk:Kovposch#Double_"parking"

If you mean the regional post, sorry I don't read German, so I didn't notice it https://community.openstreetmap.org/t/parken-in-gekennzeichneten-flachen-erlaubt/113946/
From translation, I don't see how `parking:*:restriction:conditional=`can co-exist with `parking:*:restriction` nicely for this. `parking:*:restriction=` already refers to the `restriction=` in that `parking:*=` . Adding other things there over-complicates that.
Furthermore, this is a travel lane. `=street_side` is deprecated. This will be treated as `parking=no` if there's no bay. `* @(parking=no)` is awkward.
`parking=` is a physical location, that's not the same as conditions. This is akin to suggesting `foot:conditional=* (sidewalk:*)` over `sidewalk:*:foot=` .
Using `*:lanes=` to refer to lanes seems logical and acceptable.
It's a common layout around here. You can see here the double solid yellow line continues along the dashed-lined bay on the right https://commons.wikimedia.org/wiki/File:HK_中環_Central_金鐘_Admiralty_龍和道_Lung_Wo_Road_Tim_Wa_Avenue_night_November_2021_SS2_03.jpg

So it's not based on a legal default that shouldn't be added. We clearly distinguish whether stopping is allowed outside parking bays here.

We have double "parking"/stopping restrictions here. The double solid yellow is marked between the parking bay and the travel lane.
This question has been asked in eg osm.wiki/Talk:Street_parking#no_parking_on_lane_scheme_problem
The forum post doesn't answer the case here, because it's marked. The stopping restriction can be unmarked (allowed), single solid yellow, or double solid yellow https://community.openstreetmap.org/t/street-parking-scheme-not-comprehensive-enough-needs-position/103171/

1. Please don't add bracketed descriptor labels to `name=` , which is for proper names only. Don't make them up artificially. Use `description:zh=` for such text.
2. `=exhibtion _centre` means a large exhibition and convention center for shows and events, not any facility exhibiting something. I'm not sure what this should be, but it could be eg `=museum` first.

Please discuss this controversy before you change `old_name=` to `name=`

I believe `traffic_sign=none` was discussed to mean no plates, but there can be markings https://community-cdn.openstreetmap.org/uploads/default/original/2X/c/cec22899d55dead5714839e00eb430e9f6f92037.jpeg https://community.openstreetmap.org/t/fahrradinfrastruktur-tagging-realitat-und-fragen/8417

And where is this documented or discussed?
On the contrary, markings were stilll discussed around that proposal https://community.openstreetmap.org/t/large-scale-change-of-traffic-sign-to-traffic-sign-id/107508/61
`=GB:1003A` doesn't have that many more `traffic_sign=` than `road_marking=` . It was seemingly added by someone for self-docuemntation. That still doesn't explicitly show it is marked but not signposted. It may be incomplete data. osm.wiki/w/index.php?title=Tag:highway=give_way&oldid=1641607
Instead, `traffic_sign=` has 10k `=none` and ~800 `=no` . These are more likely to mean there is no plates, rather than no traffic control devices including markings.

The application and rendering of signs is completely different from markings. Mixing them in `traffic_sign=` directly causes a mess (including to applications using them now), and requires more processing to identify whether they are panels or markings.

Should the use of `traffic_sign=` be redefined to include markings? I have only seen you suggest this now. Diluting it still pollutes the data.

Fundamentally, in this direction of thinking, `road_marking=` could still be treated as a combination under some hypothetical `traffic_sign:*=road_marking` ...
Similar to the possibility of "signs" being fixed plates, flip-flap, or LED display, markings can be paint, surfacing (bricks) , studs, reflectors, Botts' dots, etc. This is complex enough.

1. The common language connotation is preferable over some legal interpretation. Despite being titled "Traffic Sign" , Vienna Convention is still split into chapters of "Traffic Sign" and "Road Marking". Under TSRGD, UK's Traffic Signs Manual still mentions "on the correct use of traffic
signs and road markings ". https://assets.publishing.service.gov.uk/government/uploads/system/uploads/attachment_data/file/773421/traffic-signs-manual-chapter-05.pdf
2. What would be the reason to use `traffic_sign=` , when markings already use `road_marking=` ? They aren't using `traffic_sign=solid_stop_line` . It has been suggested this be continued. osm.wiki/Talk:Key:road_marking#Stroke_details
3.1. `road_marking=` is not freeform text. Language suffixes don't have to apply. `url` is the Urali language. Does `*:url=` need to be banned? I don't oppose to alternatives eg as in osm.wiki/Key:osak:identifier , but `*:id=` is popular enough now.
3.2. `traffic_sign:id=` was rejected for many reasons. I voted against the proposal, but the idea isn't bad.

Please notice that tower-on-podium architecture is standard in HK. `building=` is used by convention. They are considered different buildings. `building=` + osm.wiki/Key:building:min_level is allowed.
`building:part=` is best used for a single tower, and parts of each tower.

I'm transitioning from `road_marking=` to `road_marking:id=` as words are predominant in `road_marking=`

This is obviously not a `traffic_sign=`

1. Please don't delete roads that will be reopened. This wastes others' work, and causes more work in the future. It's bad for applications with low data update frequency.
2. There's an overlapping segment in slip road. It has no raised separation on the other end.

Please don't connect left-turn slip lanes to the same point of the main lanes. This distorts the left turn.

1. What should be used here is `addr:suburb=`
2. Please stop reusing the same unrelated comment. It pollutes that project, this changeset, and your image.

1. You removed the learner driver restriction
2. The *:lanes:conditional=` syntax is wrong. JOSM has a bug. That's not what is complaining.

This is a less simple issue. Many "Playground" were `=playground` before wrongly, which is defined for children's playing only. I corrected them to `=sports_centre` to emphasize they are for sports, and differentiate from other "Park". `=sports_centre` is not limited to indoors.