Why a database centric solution isn´t a good idea
I don´t agree at all with number #4 in your text. Of course you are right in the fact that if you use the database as the metadata master like Lightroom always have done, you don´t technically need either DOP-files or XMP-files to store the metadata but then you will live in a “single point of failure” context that I have described above as an uneccessary vulnerable configuration.
One of the most important effects of storing metadata in XMP is that it gives you a much more rubust distributed metadata configuration. In that case each and every XMP-file or XMP-compatible file like DNG, TIFF, JPEG and even textfiles like PDF owns the metadata. If one of these files gets corrupted you will lose that specific file only and the metadata it stored but if you get a corrupted metadata database like the catalog in Lightroom you risk to loose absolutely all of your metadata. If a catalog in for example Photo Mechanic gets corrupted it´s just to reindex since it´s built by reading the metadata in the files. It´s a hell of a difference.
Keep it simple
I think Bryan has done a great job looking at these problems from all sorts of angles but I think his practical recommendations are a little overcomplicated. If users should get overwhelmed by all these different switches I think @platypus “suggestion to DXO” will be a better way forward. If we get a solution where we can choose between two separated automatic sync functions - one for reading and one from writing from and to the metadata containing files, it would be a great start. And in my workflow I want that read data propagated to the database as soon as i open an image library so the database automatically is kept in sync with the XMP in the files. I don´t understand the specific need for any “Add”-versions in the flow since I think “Add” should be “Overwrite” instead. If that modell would be used it would heal a conflict automatically. What I definitelly don´t want is a conflict resolution system that is manual or semi manual. If it isn´t automatic it will ruin your work flows efficiency.
If you don´t like the words “Read” and “Write” we can talk about “Data owners” instead - either an “External system” owns the data or Photolab. When for example Photo Mechanic owns my data I don´t see that it shall be allowed at all to maintain metadata in Photolab. In that case I want DXO to inactivate all the metadata elements in Photo Library. If I should choose to let Photolab own the data then Photolab should overwrite the XMP-data in the images and unlike Lightroom it should also always update the metadata in the files to ensure a possibility to recover after a disaster. Because if that should happen the user just needs to point to the topfolder (remember?) and reindex again and the ones wanting to migrate cound pretty easy index the very same metadata in another system and start to use that instead if that is what they prefer.
Since there is a database in Photolab it has to be in sync with the XMP-metadata in the files. This is extremely important. I have written that DXO has done a fantastic job migrating both the data and creating a flat vocabulary completely automatic out of the non structured keywords used in the files when indexing my XMP-metadata from Photo Mechanic. So it should be very easy to migrate from Photo Mechanic Plus to Photolab Photo Library BUT it sure doesn´t look as great if some one decided to go the other way today 
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.
Platypus feature request:
Separate Metadata Read and Write options - DxO PhotoLab / Which feature do you need? - DxO Forums