That might work. Or maybe acting on RAWs and onphotos as pairs - see below.
I went back and tried to make my experiment more rigorous, to try to isolate sidecar behavior from the behavior of ON1 RAW's live database.
If I start with a RAW file and edit it, then add a layer to make an onphoto, I end up with four files: a RAW, an on1, an xmp, and an onphoto.
If I leave ON1 RAW running and remove the RAW, on1 and xmp files, a new on1 is generated for the onphoto and all is well. *
If I quit ON1 RAW and remove those files, no on1 file is generated for the onphoto. When I then go back to the onphoto, it retains its edits (from the database, I assume.)
If I then move the onphoto to a new folder - it does not retain its edits. If I reunite all the files in the new folder, the onphoto regains its edits. (And the RAW retains its edits).
From this, I conclude that the onphoto's edits are carried in the parent RAW's on1 file.
If, on the other hand, I rename the onphoto in the first step above, or go back to it after removing the parent's on1 file and make an edit to it, a new on1 file is created for the onphoto and it appears to become independently portable.
So, it would appear that the risk is if a RAW and its sidecars are moved or deleted while ON1 RAW is not running, a related onphoto could lose its edits.
I'm not sure what could be done about that - throw an error if the user tries to act on a RAW file when an onphoto of the same name is deteced? Seems complicated at best.
If ON1 RAW simply always wrote an independent on1 file for each onphoto, it would seem to me that the issue would go away. They might be willing to do that. I would think it would make things more stable for them generally.
Maybe if Photo Mechanic acted on all four files if an onphoto was detected and threw a warning that informed the user that onphotos and their RAWs were treated as pairs, like RAWs and JPEGs? Does that seem like it would work?**
And maybe that phone call to your opposite number at ON1 might be a good idea indeed.
As complicated as it is, this might be an issue for another day. As much as I personally would personally love to be able to move or delete files paired with their ON1 sidecars.
* The onphoto's IPTC metadata appears to be in its on1 file. Onphotos don't seem to care one way or the other about .xmp files.
** An onphoto seems to be related only to a single parent RAW. Layers subsequent to the first one - that came from the "parent" raw - seem to basically be copies of the RAWs from whence they came, stored in the onphoto.
****It would be great if somebody would try to replicate my results. There are a lot of variables and gobs of ways I could be off the tracks here. ******
