If you're going to try btrfs, check if your system/tools handle the space overcommit correctly. Some ways to check the available space don't really play well with snapshots. (As in, they report less space available)
Proceed by making another r/w snapshot for the/each subprocess.
Just work inside that folder (which behaves ~like a CoW bind-mount) and copy the artifacts into the "common" snapshot.
btrfs sub del -c path/to/temp/build/snapshot
will clean it up and ensure it won't reappear after a crash. You can skip the -c if you don't care about it reappearing.
If you have enough space to handle up to maybe a couple minutes delay in garbage collecting, you don't need to force any special syncing or such, as it just happens in the background.
As for the phases, I don't think this is a problem. btrfs snapshots are like git branches that don't allow merging, leaving explicit copy as the only recourse.
Just to make sure: This is per point-in-time, and not just because of history? You can usually make things somewhat cheaper just by doing a shallow clone. But of course that doesn't help if at any given point-in-time the repo is still too big.
And he said even deleting the diffs in an overlay is too expensive, which normally should be cheaper than deleting a worktree.
Very interesting. Thanks for sharing!