I would not consider a backup program "safe", "failsafe" or "reliable" if it stops working just because it left some arbitary file after a crash and refuses to write backups after that until someone manually removes that file. And I wouldn't consider it "safe", "failsafe" or "reliable" if it stops working because some long-running daemon accidentally has the process ID stored in that file.

PID files always cause race conditions, that's why I don't use them.

For daemons, the daemontools work fine without PID files, and as a nice side effect of the management done by daemontools, there is at any time at most one instance of any daemon under control of daemontools.

For other programs, one has to define for which "circle" the "only one instance at a time" rule applies. Only one instance per machine works fine with a lock on the executable itself. Only one instance per machine per user already becomes difficult, because locking the executable would lock out other users. So one has to use a dedicated lock file below the users home directory. Only one instance per local network can become really tricky. With a distributed lock manager, you could still get away by locking a file on a shared drive, else you would need to implement some kind of IPC. And as soon as the circle becomes larger than a network of connected machines, I don't see any technical solution to prevent multiple instances.

Alexander