OpenStreetMap

If you've got software that can't handle OSM values with units it sounds like a bug in the software to me. Please don't change OSM data when you should be fixing broken software.

It has nothing to do with software. The wiki is very explicit when it comes to weight:
Therefore if a maxweight for a country that uses U.S. customary or Imperial measurements is desired, a conversion is required.

https://wiki.openstreetmap.org/wiki/Key:maxweight

"The wiki" is not "OpenStreetMap". The most scarce resource we have is mappers. Anything that we do to persuade mappers (especially in the US) to stay away is counterproductive to the project. Please do not make US data harder to use for map consumers and mappers alike.

Why is this harder to use? In fact consuming values like this is very confusing. The mapping software should make it easier with conversion, so I my counter argument is: your mapping software should be improved to make consuming the data easier. And an important btw: such a value '15 us tons' is used VERY rarely world wide (and therefor for US too)

Just have a look here: http://taginfo.openstreetmap.org/keys/maxweight

And I agree with you that the mapper is very important (I do not agree on the term 'resource' ;)). And so we should fix the mapping software making converting US short and long tons etc into tons.

Also I do intend to change 'lbs' values because they are a lot more frequent and kind of 'unwikied' standard, so I also do not think 100% that the wiki is OSM.
But e.g. I intend to change 'lb' into 'kg' because such values are also very infrequent.

It's fairly likely there is a sign that says "15 tons" somewhere there.

One argument that this is harder to use is that no existing editor is smart enough to take "maxweight=13.607" and show the user "15 tons", so it's more difficult to verify.

Firstly, show me the sign that says "13.607" - I'm guessing that it won't exist. What exactly is a local supposed to do when they see this value in an OSM tag? They will have no idea what it means.

If "consuming values like this is very confusing" then bluntly, you're doing it wrong. For many years I worked on large statistical systems that dealt with thousands or millions of data points. Always there will be outliers - stuff you can't trust because it "makes no sense in context". With user-contributed freeform data you get exactly the same problem. it's your job (as it was mine), when writing software that deals those values to handle "things that can't be understood" or "are probably wrong" to do the best you can with such data - ignore it, convert it, whatever. Just changing a few values in OSM will achieve nothing - if mappers don't know any different they'll add "15 US tons" next time too, and you'll have the same problem again

An an aside, the reason why I suspect you found few US specific values is that previous recording had been tagfiddled away. For example, http://www.openstreetmap.org/way/32719427/history (changed 3 years ago by a different mapper) now shows an incorrect value.

Also, just in case you're not aware, OSM has a policy in place for under what circumstances automated edits should take place. In particular it says http://wiki.openstreetmap.org/wiki/Automated_Edits_code_of_conduct#Document_and_discuss_your_plans "you should discuss and document your plans beforehand". I'd suggest that all of your units changes (and also key changes such as maxweight to maxaxleload) deserve to be discussed - if only in the latter case to make data contributors and other data consumers aware that "maxaxleload" is an OSM tag that is already in use.

I think that values of maxspeed, maxweight, maxwidth etc. should have the unit they have in reality. If maxweight is signed in US tons on US roads, it should be tagged as US tons.

Every data users who wants to show the maxweight value in US tons (the original unit used on the signs) has to convert and round your metric tons value back to US tons just because one developer did not want to write code to convert US tons into metric tons.

Unit/Coordinate transformations are often lossy. That's why the original unit should be preferred. It is not difficult to convert units. You just have to hold a list of units and their conversion factor.

When do you propose to convert all UK maxspeed=* to kph?

This wasn't an automated edit.

And I disagree about the tagging here. Because messing in every unit is not only ugly but is just a lot simpler if done on the editing side. OSM is a database AND not necessarily 'readable' by humans (although partly important I of course agree)

A good editor would read the value and convert to the readers preferences. The same for writing the value.

I don't see how it is objectively simpler on the editing side.

A consumer can parse the US tons and just multiply to get tons.

An editor that wants to show US tons, in a way that sensibly matches the signs on the road, has to calculate the conversion, 14.9991 in this case, and then use some heuristic to decide whether to show that or 15 (yes, rounding will work fine here, but the point is that convert to store loses information).

My argument is that OpenStreetMap is a database and should try to get more concise over time. Also there are so many units and possible combinations why not just stick to lbs or tons?

Please see my blog post why I think it is necessary to move at least parts of the unit conversion step to the editor:
https://karussell.wordpress.com/2015/11/01/units-in-openstreetmap/

Furthermore the usage of 'US tons' was 5 world wide. And that before my edit ...

I would assume any weight restriction in the U.S. is tagged in short tons because that is what is on the sign. That's how we tag other things. maxspeed=60 mph. maxheight/maxwidth=13'3". Why should weight be any different? The only thing that makes this more complicated is that "ton" can have 3 different meanings but that's a problem to take up with the english language, not the tagging philosophy of OSM.

This language ambiguity should not infiltrate OSM tagging. So I would either define max. one unit per country or just one unit world wide and move the conversion towards the editor