Sorry if this is a long walk, I'm trying to explain how I got here in case there's a better interpretation.
tl;dr: I think that, if pingsender is still running when the updater attempts to rename the install directory, the update will fail. This might be happening for me due to a particularly slow network.
For the past few days I've had a number of failures when the updater is trying to replace the install directory with the new staged update, the logs indicate that this is because the old directory is still in use:
Begin moving destDir (C:\Program Files\Firefox Nightly) to tmpDir (C:\Program Files\Firefox Nightly.bak)
rename_file: proceeding to rename the directory
rename_file: failed to rename file - src: C:\Program Files\Firefox Nightly, dst:C:\Program Files\Firefox Nightly.bak, err: 13
PerformReplaceRequest: destDir rename attempt 1 failed. File: C:\Program Files\Firefox Nightly. Last error: 32, err: 7
13 is Posix errno EACCES, 32 is win32 ERROR_SHARING_VIOLATION. 7 is our general code for the rename failing, WRITE_ERROR.
This retries 10 times, sleeping 100ms between, and then fails, which causes Firefox to eventually show the manual install prompt once it restarts. If I instead exit Firefox, and then manually start it (so that some time passes before it starts and attempts to run the updater), it will succeed.
Today it was able to succeed after 4 failures while I had Process Monitor logging (though I mistakenly lost it before saving). I noticed that, between the unsuccessful and successful attempt to open the directory, pingsender.exe was in the process of shutting down and it closed a handle on C:\Program Files\Firefox Nightly. (When I get a chance to recreate the procmon log I need to check if this was the last of the three pingsender.exe processes that had been launched.)
I don't think pingsender opens this directory for any particular reason, it just happens to be the working directory of Firefox and so it gets inherited. For this to not be a problem with the updater itself we change it's working directory to a system directory.
It's weird that this just started happening for me recently. My best guess is that it's because I started testing a VPN Nov 12, perhaps this added enough latency to keep those pingsenders from finishing. I intend to perform some more tests without the VPN but with some artificial delay to see if I can reproduce it reliably.