theeth - not trying to be snarky here, but I have some honest crits of this technique. If you think they’re workable, great - you obviously have a much better sense of what’s doable in the code than I do.
EG: Root bone moves the object. IK targets, which should remain in place, also move with the object. Feet/hands/etc. slide. Do you really want to perform an inverse translation on all IK targets when the root bone moves the object? You either do that, or the animator must keyframe their motion backwards to take the object motion into account, which is what you were trying to avoid having to do in the first place. If you go this route, I think that you then have to implement keyframable world-space pinning of joints and/or bones to alleviate this new problem.
And isn’t this tantamount to allowing keyframing at the object level to be included in Actions? It seems like it to me. If not, how would it differ, functionally? If so, wouldn’t it be more flexible to just build support for object-level framing in the Actions system?
Now if someone wants to do something really useful, create a constraint type that allows you to set a “floor” for bones, definable either numerically, or by object reference. Bones/objects with this constrant (hello, foot bones!) would not pass below the specified level.