With the approval of the crossing:markings=* proposal there is now a satisfactory way of tagging whether a crossing is marked or not regardless of the crossing being uncontrolled or having traffic signals. For signals, there is crossing:signals=* which fulfills the same role but has not been formally approved yet.
As such, I propose to approve crossing:signals=* and additionally deprecate crossing=* (except crossing=no).
Please sound off your feedback and comments here, the corresponding mailing list or on the wiki talk page.
I am aware and my intention was to propose both together. I have discussed the similar proposal you linked and will support approving that one should this one fail. The latter one doesn’t include the deprecation of crossing=*.
Have you already had contact with data consumers about this? When deprecating such a common Key (7 million uses) I think your proposal should have a more detailed migration plan.
There should also be a clear plan for updating editors (iD, StreetComplete, etc).
iD was recently updated to include support for crossing:markings=* but in doing so changed crossing=marked to crossing=uncontrolled for its “Marked Crosswalk” preset and will likely need to be updated again pending another change to crossing. Current discussion
it is probably better to wait for reply of @riiga - but you can copy existing abandoned proposal and continue proposal process (or take over existing one if fully abandoned and you like it as is and author agreed or is not responding for looooong time)
This proposal is more specifically about formalizing crossing:signals=* along with the addition of two optional values that are useful in some regions. I would prefer tackling this issue separately from the idea of deprecating crossing=*. The main thing holding up the crossing:signals=* proposal is what to call separate and shared. But we should probably discuss that in a separate thread to avoid confusion.
What’s missing on getting it through, you think? Although I see the value of deprecating crossing, I fear that part could add some friction. In that sense @Minh_Nguyen’s proposal could be the way to go. But, as he mentions, he has naming issues to figure out (which amount to solving the hardest problem in computer science). Just getting crossing:signals=yes/no though would get us far enough for my purposes.