How it works
Nested IK bones
Why the order matters when one IK bone hangs off another.
On the mannequin, one IK bone hangs off another:
ik_hand_root -> ik_hand_gun -> ik_hand_l, ik_hand_r
ik_hand_gun is itself baked, from hand_r. So by the time ik_hand_l is written, its parent has already moved.
Why that matters
An animation track stores local transforms. A bone ends up where its local transform puts it relative to its parent. If the parent moves and the child's local transform was worked out against where the parent used to be, the child lands somewhere neither of them intended.
For ik_hand_l under a baked ik_hand_gun, that error is the size of the right hand's motion, so the hand IK bones drift off the character entirely.
What the plugin does
Pairs are baked parents before children against a single working pose, so a child's local transform is worked out against its parent's baked transform rather than the one it started the frame with.
Source bones are read from an untouched copy of the pose, so a bone that has just been written cannot drag a later pair's source along with it.
The result is what the hierarchy was designed for: ik_hand_r sits exactly on ik_hand_gun, and ik_hand_l is stored relative to the weapon anchor.
ik_foot_root is never baked, so ik_foot_l and ik_foot_r always had a parent that stays still.