I’ve daydreamed about something like this ever since I first joined OHM a couple years back. OHM seems like an excellent opportunity to rethink OSM decisions to some extent. The challenge is always that, software-wise, we operate as a very lightweight fork of OSM due to very lean developer resources. So far, we’ve tweaked the tagging conventions somewhat, such as to introduce subscripted sources, but have never touched the underlying data model in OSM XML, even for something as fundamental as start and end dates.
Just as Wikidata usually expects one of the competing claims to be “preferred”, we still need to pick a winner, so that renderers and geocoders can deterministically display a name that causes the least surprise. To the extent that there are contradictory claims to note, we can relegate them to subkeys or key variants such as alt_name=*. The only variant name key in OSM that doesn’t make so much sense here is old_name=*.
One of the tweaks we have made is to attach sources to individual tags, for example, alt_name:source=*, alt_name:source:2:date=*, etc. iD has basic support for these source subkeys (the @ button on each field). Logically, other qualifiers are possible, such as alt_name:note=*. However, we’ve moved away from the idea of qualifying tags by dates because it’s too difficult to implement even basic functionality using such tags.
Given our current data model, I agree that we should lean on Wikidata to more clearly express discrepancies in metadata, whereas Wikidata would naturally lean on us to express geometric discrepancies, which we’d model as separate features. I’ve often gotten to the point where I’ve gathered enough nuanced metadata about a feature that I feel an acute need to recreate it in Wikidata. Tools such as QLever enable data consumers to access the data regardless of where it’s stored.