Gert,
I have installed pCloud on my system and investigated the problem.
Findings: PM checks the case of the extension of the image file (for instance .CR2 or .cr2) and then checks for attached files using the case of the image file first and if that fails, then the opposite case.
So when PM creates the XMP file when editing metadata, it honors the user's settings (you chose lowercase extensions), even though they don't always match the case of the source file and creates a lowercase .xmp file. Later when the attached files list is purged and the attached files are scanned, PM asks, does there exist a file with the name filename.XMP? (because the image is filename.CR2 it starts with uppercase XMP) The pCloud filesystem responds with yes, there exists a normal file with that name when actually no such file exists.
When PM is instructed to save the XMP sidecar file again (user edits metadata a second time), then PM updates the file that it had attached to the image (with the .XMP extension) and thus the second file is created.
Basically, the filesystem that pCloud emulates on Windows lies about the existence of files.
You can see that even Windows is confused when you try to select both XMP sidecar files and delete them. It gets an error saying that one of the two files is no longer located in that folder and gives you options to "Try Again", "Skip", or "Cancel".
I suggest contacting pCloud and see if they can truly make their case-sensitive filesystem work correctly. No filesystem should say a file exists (when asked by an application) when it in fact does not exist.
I cannot write code to work around a filesystem that is inconsistent when tested.
-Kirk