Maybe we can remove these files after unlock.

The version-specific locks are used in two places:

Since those guard the creation of .zip files and extracted directories, it might be possible to remove those lockfiles after the files and directories are created.

Deleting lockfiles is subtle, and it would be very easy to introduce races that way. On POSIX systems we use advisory locks, which do not prevent the file from being changed or deleted by another process while locked. Consider the following sequence:

• Processes A locks list.lock and begins updating the list file.
• Process B attempts to lock list.lock, but blocks because it is held by A.
• Process A finishes with the list file and unlocks list.lock.
• Process B acquires list.lock.
• Process A deletes list.lock.
• Process C sees that there is no list.lock file, creates one, and locks it.

Now processes B and C are both updating the list file.

To fix that situation, we would need to always delete the file before unlocking it, and always check the identity of a file after locking it.

• Processes A locks list.lock and begins updating the list file.
• Process B attempts to lock list.lock, but blocks because it is held by A.
• Process A finishes with the list file and unlocks list.lock.
• Process A deletes list.lock (or renames it away).
• Process A unlocks the (deleted) list.lock.
• Process B acquires the (deleted) list.lock.
• Process C sees that there is no list.lock file, creates one, and locks it.
• Process B checks the file it locked to ensure that that file is still list.lock, discovers that it is not, and restarts the locking procedure.
• Process B attempts to lock the new list.lock, but blocks because it is held by C.

That requires a much more intricate locking sequence (B needs to verify the identity of the file it locked), and I'm not entirely sure that it's portable (I don't know whether Windows allows locked files to be removed or renamed).

See previously #29434.