A proper solution could be to store references to tags instead of tags themselves.
That way when a tag change is proposed all older tags will be updated in the new schema but still work in the old one, and all new tags will be backwards compatible with the old schema.
So, proposal authors could specify with tag a new tag will be in the old schema. For example, you could specify that highway=busway would look like highway=service for data users on the old schema.
I rather interpret this conversation as the landcover proposal not being viable within the current context (i.e. the absence of a deprecation/versioning process). That is, it makes sense to put it on ice for now and instead focus on versioning etc. (possibly using it as a usecase), but then re-visiting it when we have the infrastructure (both technical and non-technical) to handle such a change.
can you illustrate with landuse=farm how this would help solve the issue?
While a tagging scheme such as one of these is possible, āversioningā can mean many things (and I think even calling it āversioningā might be limiting, as there might be approaches that donāt really have anything to do with versioning but that solve the same problem).
Earlier in the thread I posted a few possible approaches:
All these, in various ways, solve the same problem (migrating between tagging schemes), all have trade-offs, and all will have (vocal) opponents. As @stevea says, devising this is a huge undertaking (but an important one, possibly even one of the most important ones OSM will undertake if it wants to stay relevant).
āThe current contextā is OSM right now. The Proposal is effectively ādead on arrivalā (sorry to be harsh in my wording) with the structure (both social and technical) OSM has right now. It would certainly need to be updated (as a v3?) if and when a comprehensive (clearly longer-term) solution might emerge along the lines you suggest. But to put it āon iceā as it is now and expect that we could simply āthawā it with what effectively would be a new paradigm for OSM tagging is unrealistic.
Just my opinion.
(since I canāt use it as a reactionā¦)
It was never viable. Not because the discussion here is long, but because the proposal lacks a fundamental understanding of the technical landscape of the project. The length of the discussion simply serves as a body of evidence for the next time someone proposes an unreasonable change.
Thatās pretty much exactly what I said 
It is not viable right now, but it (or rather a future iteration of it) might be once OSM āis ready for itā.
It might be possible to just pick up where it is now, it might need to restart from scratch (that will depend on how a tagging-migration-solution ends up being), but regardless one should look at what was already done and discussed.
Then, solve it, and be prepared to show your work. Whether this is a dismissal or a call to action only depends on your personal level of interest and motivation to roll up your sleeves and demonstrate a solution. Iāve certainly been told that āif you donāt like it, do it betterā and then gone off and done so on this project. Iāve built software, executed hard tagging changes, and spoken at conferences and on YouTube on my exploits. And, Iām nobody. Just a hobbyist that felt like it.
Your language is in reverse, I think. OSM is not some entity which you sit outside of and chastise it to do better. OSM is you. Itās me, itās @stevea, itās @SomeoneElse entirely. Itās a software developer, an end user, itās the OSM Foundation Board, a working group, a local chapter, an activist, a hobbyist. Itās nobody in particular. But it IS individuals that have seen problems and said āI can do betterā and come up with the goods. Thatās the reality in a decentralized project.
āOSMā doesnāt undertake anything. Individual contributors do.
true, but is them up to them to find and fix the issue before distributing updated dataset to their users.
IOW, (theoretical) improvement of using such dataset would be that when tagging style changes, only one place (Overture or whoever) has to worry about it and do backwards-compatible fix; instead of every data consumer having to handle it.
Of course, it also creates another set of problems, not least of which being that tagging structure is ossified there, and you can not do any improvements in data tagging, because if you change or introduce any new type of data, youāre back on square one. Also since one had to check if there has been vandalism or new or changed tags before releasing, there would be delays in updated maps, but that can be an advantage too sometimes.
An actual versioning and backwards compatibility solution for OSM would allow a period of time where mappers could submit either v1 or v2 tags to the API and consumers could get data out with either v1 or v2 tags. A translation layer on both ends would be required. With the tag agnostic philosophy of the project this seems unlikely to happen.
If someone would like do such translation (which I donāt see as an idea with particularly useful); may I recommend (instead of such ugly extra-tag-prefix/suffix kludge) to instead create new API endpoint instead.
e.g. currently this API endpoint https://www.openstreetmap.org/api/0.6/relation/5876272 returns some XML. One could easily create implement translator API at https://whatever.example.com/api/0.7/relation/5876272 which would return that object in the way that they find preferred (e.g. replacing all natural=wood or landuse=forest to landcover=trees or whatever other change and reasoning one might have to deprecate/rename tags), e.g. it would ātranslateā regular OSM-ATYL-tags to my-more-rigid-and-clearer-set-of-tags, like this:
<?xml version="1.0" encoding="UTF-8"?>
-<osm version="0.6" generator="CGImap 0.8.10 (412697 spike-07.openstreetmap.org)" copyright="OpenStreetMap and contributors" attribution="http://www.openstreetmap.org/copyright" license="http://opendatacommons.org/licenses/odbl/1-0/">
+<osm version="0.7" generator="My New Cool API 0.9.37 (116321 whatever.example.com)" upstream="CGImap 0.8.10 (412697 spike-07.openstreetmap.org)" copyright="OpenStreetMap and contributors" attribution="http://www.openstreetmap.org/copyright" license="http://opendatacommons.org/licenses/odbl/1-0/">
<relation id="5876272" visible="true" version="6" changeset="118694112" timestamp="2022-03-20T12:24:14Z" user="Muki MaÄkoviÄ" uid="3636444">
<member type="way" ref="87194173" role="outer"/>
<member type="way" ref="392034935" role="outer"/>
<member type="way" ref="753330854" role="inner"/>
<member type="way" ref="1041941121" role="inner"/>
- <tag k="landuse" v="forest"/>
+ <tag k="landcover" v="trees"/>
<tag k="name" v="Park Å”uma GrmoÅ”Äica"/>
<tag k="type" v="multipolygon"/>
<tag k="wikidata" v="Q97353235"/>
<tag k="wikipedia" v="hr:Park-Å”uma GrmoÅ”Äica"/>
</relation>
</osm>
Then people can then easily change their JOSM (or whatever) configuration to use that new API endpoint; and enjoy in their new&improved OSM tagged worldview.
The same modifications (if wanted) can be made for objects being PUT on the server, if you prefer to upload only the ānew and betterā tags instead of the equivalent-tags that user has specified (you probably should create an explicit changeset tag that indicate you did such auto-translation, though)
The best thing? One can do that right now with minimal effort (certainly one or more orders of magnitude less effort than this discussion has entailed so far), and one can test and develop such project on any small server/VPS, and gather smaller (or bigger) number of enthusiastic beta-testers to improve and test it before proposing it as an official one. And even if it is not accepted as official one, who cares? The ones who elected to use it would still reap all the benefits that such tag deprecation/renaming (supposedly) entails.
I think you should look at the context of both times I posted those suggestions; the first time to exemplify that it is (or might be) possible to have a scheme that allows changing tags in a consumer-friendly way, the second time to exemplify other alternatives to prefix/suffix versioning.
Iād love to take a stab at this in a more serious manner, but considering that I already have two rather major OSM-related projects Iām working on right now which are already consuming most of my free time I have to politely decline.
I was referring to OSM as an āorganismā or a community, as this is not something any one single person can do. Sure, it will require one or a few heroes who pull the community together around the task and do a large share of the work, but in the end it will go nowhere without the involvement of a large part of the community.
Do note that your comment comes across as somewhat condescending. Iām well aware what drives a project such as OSM forward.
ālandcover vs landuseā has been debated since at least 2010. This particular thread isnāt even a year old yet. 
OSM (with its completely free tagging) has succeeded where other competitors have failed, just like wkipedia succeeded after nupedia failed.
Whatās allowed OSM to be successful is allowing anyone to describe their local area so that they, or other people, can make a map from it. Restrict that, and you restrict what people can map - which wouldnāt be a good thing. That doesnāt mean that there canāt be a role for a set of data with a more or less fixed schema so that the problem Brian described above is less of an issue, and yes, the schemas for OpenMapTiles et al do intend to nail things down a bit so that a consumer of (say) vector tiles claiming to be using OpenMapTilesā schema donāt have ālots of data suddenly missingā - but what Zeke said above is true - and it does mean that if people suddenly have the urge to change the tag in OSM for concept X from tag A to tag B, theyād better have a pretty good reason. One to one changes that literally add no value are NOT a good reason.
Maybe an example would help. I look after a couple of different sorts of maps - web based ones (click the changelog link to see more details and links to the sources of the components) and Garmin / mkgmap ones, source here. Where possible both use more or less the same schema, so that the way that I round up all possible taggings of (say) ābroadleaved woodlandā is the same in both cases, but the resulting map style code is very differentā¦
If someone decides to change all tag A to tag B in the data, each map will just āsee fewer examples of broadleaved woodlandā. Iāve seen that happen with embassies, hill forts and pinfolds. Thatās despite both those map styles being registered at taginfo, with a link to both github projects so that people can create an issue saying āIām proposing to change tag A to tag Bā alongside anything else that might apply.
Oh, dear Andy our Support moderator, thank you for both your reminder of the longevity of this issue (and related ones about tag deprecations) ā I remember 2010 in OSM, too ā as well as your helpful personal experiences.
Taginfo āregistrations,ā GitHub project links that foster good communication and many other earnest, genuine attempts at āreconciliationā (for lack of a better word, though āharmonizationā also gets closeā¦I know you might prefer the z be an s) and more are all important ingredients at how this continues to move forward.
Though, for now, may we split this topic into a new one that is more aligned with tag deprecation and let this topic continue to discover (and accept) that the Feature Proposal that it purports to be about simply isnāt viable? Thank you.
You are thinking along the right lines, but retooling the API endpoint alone is insufficient. You would need to consider all the pipelines through which data consumers get their data. At a minimum youād need to distribute parallel planet files and diffs, and likely stand up parallel overpass services to cover the most common pipelines.
All of this is assuming that the problem we identify is worth all this effort 
You mean a primitive? I am aware of node, way, relation. Out of the relation type, multipolygon as far as I can tell only ever maps areas.
I think mapping intent is missing from the list.
Where is that emoji reaction when you need itā¦ Anyway, might I suggest splitting that area data type part of the discussion to another subthread?
Sure, but only because (as you said) it has neither area=yes nor area=no tag. If you know of the real situation, you could just add area=* tag, and the problem would be solved, right? Or am I missing something else there?
And it could be done, in my opinion, without an API change. You could have some code between the API and the database that rejects changes that turn a valid multipolygon into an invalid one. Because really, we have areas, theyāre just multipolygon relations that have no integrity guarantee. The difference between not allowing users to break multipolygon relations and actual area types in the API is, in my opnion, just syntactic sugar around the core problem of ensuring data integrity.
Of course, like this proposal for landcover, areas arenāt that interesting because they doesnāt solve a significant problem. After all, data consumers are handling areas just fine ā though a little extra data integrity would be nice.
Actually, can we rename this thread to āidealistic ideas to improve OSMā ?
We could try and āmake a ruleā that all areas need to be mapped as relations (not ways), but I suspect that there would be considerable resistance to that changeā¦
(for the avoidance of any doubt I would not be in favour of any such rule)
Can someone then create another topic with āidealistic ideas to improve OSMā or should I?
So as not to divert the main topic here.