@justinwyllie The rationale behind the DxO approach when a later DOP is encountered by an earlier release is that there is a danger that the earlier release will not recognise the later release DOP, or elements of it, because who knows what might have changed.
When it ignores the DOP it will remain intact until you either export a file in the earlier release or make an edit (according to what my memory tells me about tests I have done in the past).
The action of exporting or editing will trigger the creation of a new DOP and that process is always destructive, i.e. a new DOP is created with the same name as any previous DOP and will cause the old DOP to be overwritten. A new DOP is not an update of an old DOP it is a complete replacement.
Hence, when I am testing I use separate directories for the tests, one for each release
and it appears I am less than scrupulous with my directory naming and the DP XD directory for PL8 should have been DP XD2s for accuracy!!
Typically, when doing such tests I will start with the lowest release to make the initial settings and then copy the DOPs to the higher release directories and allow DxPL to amend those DOPs if and when necessary.
In that way I am seeking to keep a level playing field with respect to any edit settings that I have made, i.e. trying to compare like with like and reduce the risk of introducing unnecessary changes.
Protecting DOPs from accidents can only be achieved by making backups, of the DOP and xmp sidecar file.
@rsp and during the early days of testing the new release you should be making backups of the DOPs to avoid the problem I have just mentioned above.
Forward compatibility of Databases and DOPs is (should be) O.K. but backward compatibility of either/both is essentially not going to work (unless you start hacking DOPs).