The general conflation problem: matching without a unique and reliable matching key, and knowing what to keep, what to replace, what to add and what to change, on both the object level and the atrribute level. I have yet to enounter a case where this is handled fully automatically and reliably.
If all the stores and their additional data were fed to OSM from an outside source, this could be done: you would have a unique and persistent matching key and you could simply add missing data, remove obsolete data, and replace old information with new. OSM-wide, this is not the case, and it’s not going to happen any time soon. In a bubble, such as one company or brand with all its stores, or every store within a small area, it probably could be arranged.
That, I would say, is for the data supplier or syndicator to solve. It sounds like they were trying to match on address, which is an unreliable string key. The key must be unique and reliable on both sides before you can expect reliable matching.
Sure. You can’t just dump stores in the vicinity, just because you want to store opening times. You can put pins with data on an OSM-based map, but they would not be stored in OSM unless you link it to a mapped object, which requires the actual and verifiable location.
If the mall is an object, I could think of a solution to specify the stores in the mall as tags, without adding them individually as objects of their own, and link opening times in the same way. But the data is too much for the OSM data model, so it would involve a key to an outside system where the opening time details are stored. And, I think this would be an awkward, error prone solution that will satisfy no-one, and the data will get stale very fast.
Same thing really. If you map different departments, they have diffferent locations; if you don’t know where they are you can’t put them in the map database. OSM is not a pin database; it’s a map of verifyable objects where they really are. This sort of data should be kept in a separate system with a unique and persistent identifier key; then it is possible to record the key in relevant OSM objects so applications can link the external system for the details.
If your data was truly and verifiably trustworthy, it should not be reverted. Could it be that the trustworthyness was not obvious or easily verifiable, and the mapper was pissed off because his/her precious survey data was replaced, without survey, with other data?