For the source code part of that, the difference between using layerfs and btrfs snapshots feels near trivial. There'd be so little difference at the source layer. Unless your changes are massive massive massive repo wide changes, most of the content is going to remain the same, and the btrfs snapshot is going to mean each workspace is a proportionally a tiny delta, have as many as you want.
I guess the win is that often build artifacts are the same in many cases, so a pristine checkout still de-dupes. There's very good build caching systems out there that help with not needing to keep re-compiling the exact same stuff you've compiled, so I tend to discredit this usage some. But each of those workspaces would end up with it's own copy of the build artifacts, so there is a real savings to layerfs in either case, with it's dedupe.
Good for you on your "speculative merge topologically sorted task list merging into a merge train". Fun hard problems to have! Great. I don't want to be too rude, but also, personally, I think you could have simmered that down a bit, at the cost of not presenting quite entirely how super advanced elite super cool you are.
Perhaps but it wouldn’t have been explicit about why I have that problem. I don’t think it’s a normal problem to have, whether it’s elite or not, it’s IMO not common. The speculative pipeline and the merge train is the key part because they overlap with changes in the same files. This is why block based doesn’t help me as much. I’d prefer to not censor myself with respect to my problem statements for some internet humility virtue signaling.