A couple years ago, @Natfoot suggested that the renderer treat construction_date=* as a synonym for start_date=*. Since then, start_date=* has become a key part of OHM’s software ecosystem, with a number of editors, data consumers, and queries depending on it. This will make it very difficult to establish a parallel key meaning approximately the same thing.
Even in OSM, both construction_date=* and year_of_construction=* are more obscure than start_date=*. I think the main reason these keys exist is that OSM tends to dual-tag a building with its occupant, making it necessary to clarify whether the building or the occupant started on the date given. Since often need to record changes in occupancy over time, it makes much less sense to conflate the building in this manner.
In OHM, construction_date=* has only 149 occurrences last edited by 14 users, a pittance compared to start_date=*. I’d like to deprecate construction_date=* in favor of start_date=* on the building and extract any occupant’s tags into a separate feature. Moreover, if there’s a need to distinguish the groundbreaking date from the completion date, we can map a separate building=construction or landuse=construction area representing the construction site between the two dates.
Practically speaking, deprecating this key would entail creating a fork of the existing key description page that explains the situation for OHM, then adding a banner to the top of the existing page that points to the forked page. We could then add an override to iD that triggers a validation warning when construction_date=* appears.
Does this approach seem workable?