I understand the allure of this approach, but it is not without tradeoffs. For one thing, it assumes a system of implied defaults, hopefully documented in machine-readable format. (Please let it not be wikitext.)
Any system of implied defaults is presumptuous when its authors lack the necessary perspective to come up with fair and intuitive global defaults. After all, we have just discussed an innocently misapplied use of “uncontrolled” from one mailing list post that our standards and presets doubled down on, despite pleas by well-informed mappers who had been tagging it according to its real-world meaning for years. This experience shows that tagging discussions need to be more representative of the wider world before we can begin shoehorning the world into an elegant system.
It may seem like we can simply handwave about regional differences by letting each region define their own tags. This comes with a tradeoff too: data consumers are less able to do anything useful with a geographically fragmented tagging scheme. That’s OK for something like school classification, for which we probably care more about enabling personal queries and regional renderers than global geocoders. But when it comes to routing pedestrians via crossings, there are relatively universal concepts like “there are markings” and “pedestrians wait for a signal”. It would just be unfair to make renderer developers become familiar with a variety of legal systems just to respond to those basic attributes. Whereas something that takes a lot of explanation, like the six required phases of a HAWK crossing, should definitely be a regional tag.
There are days when I tire of the many crossing:* subkeys for railway level crossings. Too much clicking. Because checkboxes are inconvenient, we could scrap the elaborate OpenRailwayMap tagging scheme and replace it with a simpler crossing_ref key. In my neck of the woods, there would be seven alphanumeric values corresponding to presets with self-evident names like “Flashing Light Signal Assembly with Automatic Gate Arm” (crossing_ref=9). Router and renderer developers would ensure compliance with the implied defaults in this wiki table. We’d deprecate crossing:saltire and crossing:bell as redundant and reduce our usage of crossing:barrier to less than 20% of what it is now.
Maybe if we were around in the early days of OSM, we could build up the social structures and processes necessary to make an approach like this work well. But as things stand, we have to make do with a more loosely coupled system. It’s actually not that bad thanks to presets – just don’t confuse presets with JOSM presets.
Maybe it has something to do with advocacy for crossing=zebra, but as a holistic classification rather than solely an indication of markings? It isn’t clear to me if that has ever been a prevailing viewpoint.
That appears to be a screenshot of F4Map, which renders every highway=crossing node with zebra stripes, including crossing=traffic_signals, crossing=marked, and crossing=unmarked.
A couple months ago, I added a section to each of the crossing=* pages indicating which tags are supported by which data consumers, as opposed to the JOSM presets that flood taginfo’s Projects tab. Overall, the crossing=unmarked/zebra/traffic_signals, crossing=unmarked/uncontrolled/traffic_signals, and crossing=unmarked/marked/traffic_signals schemes all enjoy roughly the same amount of support among renderers and routers, which is not to say very much. crossing:markings=* and crossing:signals=* also have nearly as much support among routers as either of those schemes, despite being much more recent introductions. crossing_ref=zebra is supported by a few renderers as an alias of crossing=zebra, but no router understands it as far as I can tell.