Perhaps a more accurate way for me to phrase this is that the U.S. does make this same distinction, but not on the mainland. Additionally, addr:place=* has always been hopelessly skunked with postal cities – that is, if addr:city=* is only for places that OSM classifies as cities. By your reasoning, the majority of addr:city=* occurrences in the U.S. need to be retagged to either addr:place=* or a proliferation of subkeys such as addr:hamlet=*, addr:village=*, and addr:region=*, or less commonly addr:island=*, addr:landuse_military=*, addr:monastery=*, and addr:office=*. It starts to resemble an is_in=* tag all over again. For what purpose, I don’t know.
If we were so unconcerned with reflecting the distinctions in each region’s standard address format, and overly concerned with what amounts to an etymology, then we would have to deal with a litany of broken assumptions, such as:
- In some older cities or on college campuses, the street may be a named, garden-variety footpath that we’d certainly tag as
highway=footway, nothighway=pedestrian. - Plenty of streets are numbered highways that we’ve chosen to tag with
ref=*but notname=*. Deriving the actual street name from a way ref or route relation would be an effort on the scale of OSM Americana. - In Queens, New York, and much of Wisconsin, a house number is essentially a coordinate according to a local grid.
This is just the tip the iceberg. And just to illustrate that this isn’t merely a U.S. issue: in Vietnam, the average urban address lists somewhere between three and six different streets by number, but it’s all considered part of the house number.
I get that we shouldn’t be overly concerned with matching the postal service’s database structure. That to me is an argument for continuing to represent the full street name as a single tag, rather than breaking it up word by word as the USPS does. It’s also an argument for continuing to keep the house number in a separate tag, very useful for rendering, even though most software keeps the whole delivery line in one database field. But I disagree that it means we need to distinguish the reasons why something goes in the street slot of an address.
That’s what most geocoders do when searching for an intersection. However, I’m not talking about user input. If a building on one corner is tagged with a corner address, then the geocoder would use the coordinates of that building, not the intersection. By analogy, many addresses name a street that isn’t the closest street, but a geocoder should be able to return the coordinates of the feature, not the street named in the address.