From a mapper ↔ data consumer point of view, this makes it slightly easier for mappers who now do not have to do unit conversion, and slightly harder for data consumers who must now do unit parsing.
This is an accurate statement about human-readable tags in general. However, from what I can tell so far, most relevant data consumers are already parsing ele=* as something other than a bare number. It’s convenient for most of them because of all the other keys that also accept units. It’s also a lot less error-prone for a handful of data consumers to implement the parsing and conversion code than for many mappers who don’t routinely use metric units to perform the same conversion manually each time they encounter this key.
The table shows for OpenTopoMap “displays the value verbatim”.
If I interpret the following post correctly, the ele tag is also used to calculate the dominance of mountain peaks.
On opentopomap the literal content of ele is displayed, regardless of units or whether there is anything that can be interpreted as a number at all.
For the calculation of the isolation, it does not matter whether you write “1000”, “1000m” or “3280.8 ft”. There just has to be any number (with a maximum of one point or comma as a decimal separator, no separation for thousands such as “1.000,4” instead of “1000.4”, please) and either no unit (is interpreted as metres) or ft or m as a unit. Apostrophes (3280.8’) are not interpreted (interpretation is done in this function)
If “ele” cannot be interpreted, the height is estimated from the DEM.
I’ve completed the info for waymarkedtrails. ft and ' work both fine.
From a data user POV, I very much prefer elevations entered in the originally available unit because it is surprisingly hard to convert a value of “304.8” back to its original “1000 ft” without running into rounding issues.
Even though I personally would prefer the world (and OSM) to be completely metric, this seems like a useful and reasonable proposal for mapping in the United States and associated territories. As long as the proper unit is indicated in the value, having more accurate data that is easily consumable is always welcome.
While it should improve the dataset a little bit going forward, I doubt it will make a big difference.
Someone who is putting in a feet figures into a metric field without notice, will not be aware - or would not care - to add “ft”. The only proper way would be to run the database and new ele entries against a DEM for +/-60 degree and flag those witha quotient of 3.1 to 3.5 automatically. And bouncing back a message to the authors to educate them - as politely as you chose.
What also would help is to improve the entry OSM entry page (I suppose JOSM and level0 users are technical and educated enough to understand the metric base of the dataset): for all fields with metricc ambiguity add a warning, to either enter the metric valuenor add a qualifier like ft, mph and alike. So nobody can claim ignore anymore. Currently the definition is hidden behind the “i” button, which people typicaly do not care about.
In iD, which I think is what you’re referring to as the “entry OSM entry page”, it currently shows “Elevation (meters)” for the entry:
Whereas for other things I’ve seen, such as the speed limit (maxspeed=), it shows the unit explicitly, and (at least in my locale) defaults to mph as I would expect. So when I was adding a few speed limits around town the other day, I just needed to put in the number that was on the sign and it defaulted to putting the " mph" as the unit in there for me.
I assume that if this proposal becomes popular, iD may end up doing something similar for elevations.
Out of curiosity, when do you encounter ele data with nice round numbers? The elevation of natural lakes and summits generally have no preference for round numbers in any set of units.
You are right, Peter, I must have been a bit blind, sorry.
One the other hand - what does this tell about people entering feet values into such a field … ?
To me, it says that they’re normal people who, like most normal people in the U.S., normally only think in terms of customary units. User education is important, but I’d rather save my breath for more important matters, like keeping bboxes small. 
Just depends on the precision of your data. If you have a source that is accurate to inches or single digit cm, that would be what you would like to enter.
For very high and remote places, like the highest mountains and the the lowest deeps, the value is even specified to single digit meters with an uncertainty that can be several dozens of meters.
For locations very close to a known or to sea level, tenths of meters and less could make a big difference. For example in Japanese costal areas, the local elevation is marked out on streets in resolution of 10 cm, and in Venice, a few centimeters may make a difference if a place gets flooded on a regular basis or stays dry.
Can’t iD just add the unit selector to the input box, defaulting to meters?
Would you summarize the remaining opposing points of view?
It could, but if you then select feet, it would have to automatically convert the existing value from meters to feet and then convert your input from feet to meters. There is a potential for conversion error in both directions, depending on precision. This is one reason why editors didn’t offer a similar UI for other dimensional fields back when we used to insist on kilometers per hour in maxspeed.
The only outright opposition I’ve seen so far, during the previous RFC, was based on concern about mass retagging. Hopefully I’ve allayed this fear by clearly stating that the use of an alternative unit is an option only. The same respondent was concerned that renderers would have to parse and convert units instead of displaying values verbatim. However, as noted earlier, most renderers already parse units. Besides, any renderer aimed at an American audience would have to convert any metric values to feet anyways, if not globally then at least when viewing the U.S., where even non-English speakers use customary units for most purposes.
Otherwise, most feedback has been receptive, with reservations that go beyond the scope of this proposal. Multiple respondents have noted that the ' symbol is not as noticeable as the deprecated ft symbol. I agree that this is unfortunate, but I would prefer that we address the issue separately as part of the more general Units page. It might need not to go through a formal vote, since no unit symbol ever has, and most data consumers already understand both ' and ft interchangeably.
One respondent pointed out that non-numeric ele values are rare compared to ele:ft. I believe this to be an inaccurate assessment and am awaiting further information. They also expressed a preference for parallel ele and ele:ft keys, in order to better capture the mapper’s intent. While I think there’s some merit to this argument, it isn’t specific to elevations, and we’ve roundly ignored it when it comes to other dimensions, to the point that length measurements can be nested very deeply inside a conditional restriction tag, for example.
On the mailing list, there has been a lot of discussion about datums, but respondents have been quick to point out that the discrepancies between datums are a problem even for elevations given in meters. I am amused to see that my offhand remark about the U.S. survey foot has thoroughly nerd-sniped that group.
Hopefully that captures everything so far. I remain open to feedback for the remainder of this RFC period.
To underscore this point, I have in my collection a Strassenkarte of the western U.S., published in Bern for Swiss visitors to the States, that nevertheless displays elevations only in feet:
I do not see: from the moment this proposal gets approved, input is not just numerical with dimension added later on? Perhaps put dimension selector front, numerical input later?
Approving this proposal would enable iD to provide a quantity-and-unit field for ele like it does for some other dimensional keys. That is, it would provide the unit option but would not automatically convert between units. Without approving this proposal, the same UI would need to convert between meters and feet, because only meters can be stored in the raw tag.
I like to think Randall Munroe has been following at least one of the OSM communication channels:
This is the first time I’ve learned of a niche topic before seeing the relevant xkcd! Thanks for granting us this nerd cred, @Minh_Nguyen!