Right, there can be multiple interpretations of sign, so maybe more specific values would be better in cases where the oneway=yes comes from a non-obvious sign. Whatever goes in source:oneway=*, it’s another signal that the mapper added the one-way tags with intention, so a data consumer probably should impart some meaning from them and can possibly get away with interpreting them more literally.
It doesn’t have to be a single key. Today, a routing profile can already infer directionality from dual_carriageway=yes on some dual carriageways and conveying=yes on moving walkways and escalators. Many sidepaths in Germany have footway=sidewalk, which might be the basis for a heuristic too. Going forward, we could tag footway=queue for single-file lines at amusement parks and airports, narrow=yes on footpaths that you can’t step to the side of, and something for those automated exit lanes at airports. There’s a long tail of possibilities if a router wants to be 100% correct…
But 100% correct isn’t the goal, not when we have a large existing body of footways, steps, etc. that don’t have this kind of detail. For these, a router needs to make an educated guess, like the educated guess they make about whether to ignore access tags altogether. The most obvious factor is the primary feature tag – the very first thing a data consumer reads to determine whether a way is relevant to the use case. That’s a simple check. It isn’t as foolproof as footway=queue, but it addresses enough cases to reduce the urgency of looking at the long tail of other keys. Some routers are considering the primary tag, to their advantage; others have yet to implement this heuristic, for whatever reason.