A long time ago (i.e. three years) no possibility existed in OSM to tag the existence of turn lanes. As more and more OSM-based navigational devices emerged, people became envious of commercial devices which often had very helpful lane assistants. So the need to provide information about turn lanes was increasing and people started to come up with some tagging schemes. I remember at least two of them in detail:
The approach from benshu with the turnlanes:turn relation. It even came with a great JOSM plugin, but it had some serious drawbacks, which prevented its breakthrough: geometric information as tag value (the length of the lane) and - the all-time-favorite-show-stopper - a relation.
The lanes:turnXXX approach from Zverik. Just like the previous it concentrated solely on turn lanes. When put on vote, it was rejected. Maybe because it involved counting, but that's just a wild guess on my side.
I felt that it is now my turn to come up with something. I dug through different proposals, read a lot of threads on various discussion forums and tried multiple tagging schemes in practice. The result was the proposal for the :lanes suffix, which was intended as universal approach for lane-dependent properties and was a collection of all the - in my opinion - good ideas from different people I found during my search. After some cutbacks and adjustments I put it on vote and it was accepted - hooray!
But getting a proposal approved and getting a tagging scheme to be used are two completely different things. Especially as some misunderstandings persist.
A suffix is a suffix is a suffix
The :lanes suffix is just that: a suffix. Just like :forward or :backward, :left or :right. All those have one thing in common: they take existing keys with their defined values and only change their scope.
Example: While maxspeed=50 tells us that the speed limit is 50 on the whole road, maxspeed:forward=50 tells us, that this speed limit is valid for one driving direction, but not the other. It is the same when using all the other suffixes, including the :lanes suffix: while minspeed=80 tells us that the minimum speed for the whole road is 80, minspeed:lanes=100|80 tells us that the minimum speed on the leftmost lane is 100 and on the rightmost is 80.
There is no change in meaning of the key nor its values, we only change the scope. (By the way: I do not think of "100|80" as the "value", but instead of the separate lane-dependent values "100" and "80".)
Most important: there is no such thing as a "maxspeed:forward" key or a "minspeed:lanes" key, there are only the keys "maxspeed" and "minspeed" with their defined values. This is also true for "turn" and "change", even if they are almost exclusively used together with the suffix :lanes!
Again: the problem with counting
A golden rule in data definitions is: keep it simple, intuitive and especially avoid exceptions. A perfect example of a violation of that rule is the definition of the key "lanes". It could have been so simple: count the number of lanes, put it into the key - done. But instead we have a nearly endless list of exceptions: only motorized traffic, only full-width, no parking lanes, no bicycle lanes, no ... oh forget it! But no one really cared. Until the :lanes suffix came, which followed the golden rule. And now we have e.g. roads with four values in keys with the lanes-suffix but only lanes=3... oh wait... no, that's another exception... lanes=2... I think. And people start asking why does the one key say three... dammit... TWO lanes and the other keys say four lanes? Simple answer: because the "lanes" key has a very bad definition.
How can we fix this? I don't know. Change the definition of a key that is used over four million times? Not sure. Is it even necessary to fix it? Not sure either. It's not a problem for data consumers, they can rely either on one or the other information. But how can we explain this discrepancy to Joe Mapper? I don't know...
P.S: A few days ago someone meant, that we need some extra definition for the :lanes suffix when used together with half-width lanes. I thought about the golden rule then...