In some navigation software, an idealized first-person view of a motorway junction appears as you approach it, especially if the junction is complex. This feature comes standard with standalone GPS units, waned for a while in consumer applications like Google Maps, and is now making a comeback with in-car navigation systems. Mapbox has a junction view feature too, but it isn’t active when using OSM-based data.
To be clear, the junction view images are always based on a mix of actual road data and hard-coded artistic hints. If you look at a Garmin junction view very closely, you might not recognize the tree pattern or skyline in reality. But even if we focus on just the destination sign in the image, it isn’t always possible to derive a presentationally correct sign based on the more semantic destination:* tagging scheme. There is a proposal for encoding the layout of the sign more literally, but it isn’t very internationalized. Making maters worse, Valhalla helped popularize destination:street, which takes the streets out of the main list of destinations, erasing information about the order on the sign.
iD is simply listing what taginfo says are the most common values of traffic_sign on a node. You can hover over a value to get the description that taginfo scraped from the wiki article’s infobox, but otherwise iD doesn’t have any information about individual values.
There are some proposals for adding traffic signs to either id-tagging-schema or name-suggestion-index. Either approach would require some additional infrastructure to handle an influx of tens of thousands of new presets.