hmmm 
If we, for the moment, forget where and how metadata can be stored, can we then agree
- that metadata reconciliation should be possible in every necessary way?
- that reconciliation gets more complicated, when more parties are involved?
I’ve highlighted “necessary”, because this is where differing requirements come in.
Let’s look at the following concept:
Metadata can appear in
- the original file (RAW or other supported format)
- the first party database (DOPDatabaseV5.dopdata)
- a first party sidecar (*.dop file)
- a third party sidecar (*.xmp file)
- other?
The consequence of the above is, that we’d need an n-way reconciliation. Given the probability that many users have different requirements (which is the important MD-carrier?), the only way to go is, to ask the user, how the reconciliation should be done, and this is not going to be super simple.
Imagine a configurable decision path
- If MD in A, then…, else if MD in B…, else if MD in C…, else if MD in D…
- IF MD newer in A, then… (can we establish, that a metadata entry is newer? what if an app does not update the MD change timestamp?)
Instead, DxO could pop up a window saying: This MD item exists as red, orange and green, which do you want? This would come as a PITA (not the delicious bread variety) but would allow the user to get exactly what is needed or wanted. This will probably never happen. 
and a real DAM has to offer the users support going either direction. Of that reason DXO also has to provide an interface for exporting and importing keyword vocabularies that people wants to use or already have used with the metadata. If they don´t provide us with that like for exampe Photo Mechanic does, then people will get stuck with a completely proprietary Photo Library and can´t migrate even if they want.
