2

OSM IDs often happen to be stable for some time, but that’s in no way guaranteed. There are many editing operations (such as merging two ways, or replacing a POI node with an outline) which affect objects’ IDs and might be performed at any time. It’s sometimes not practical to prevent changing IDs, and doing so is not part of standard mapping practice. It’s even possible for an OSM element to represent a completely different object with different tags and a different position tomorrow. The latter event is rare and usually not considered desirable, but will occasionally happen.

Nevertheless, OSM IDs might be static enough to be of some practical use, if accompanied by a fallback. It has been suggested that OSM IDs could be used most of the time because of ease of use or performance benefits, but if the object’s deletion is detected, stored information could be used to retrieve the new ID of the same real-world entity - an operation that would of course be much more costly than the regular ID-based access, but wouldn’t have to be performed frequently. I could imagine that a coordinate and some information from tags (such as rough object category, address and/or name, with the exact tags probably best chosen dependent on the use case) could work most of the time. I’m not aware of any public implementation of such fallback mechanisms.

Despite the obvious problems of the IDs, there actually are external services which use OSM IDs with no fallback solution (as far as I know) for linking to OSM, such as Flickr. However, it’s only a low-priority feature in that case, and I still wouldn’t recommend to rely on raw OSM IDs for important functionality.