What is view in that case?

Yes, definitely. I talked with Bastien about this, and he said it required some more work in Blender's internals, so I left auto-keying out of the scope of this patch.

I think our animators generally only use a single constraint on any particular bone, but I don't know how our studio's workflow generalizes to Blender users in general. Also, it would be failry easy to construct a set of constraints that make it perfectly fine to use this operator on any constraint; for example, it would work fine when using on the middle or last constraint when you have 'copy translation; copy rotation; copy scale' as three separate constraints.

If this shows on all constraints the operator should support temporarily disabling constraints after the active one.

I'm not sure why you'd want to disable the constraints *after* the active one. It's the constraints *before* the active one that cause movement when you press the "disable without movement" button.

Shouldn't this be getattr(context, "constraint", None) ? - if the purpose is to prevent an exception when the context doesn't have a constraint (when poll is called from the operator search for eg).

This doesn't support pinning, using context.object instead of context.active_object to get the data which respects pinning. Then get the active pose-bone from the object.

Can be Operator only since it's already imported.

Don't think there is a good reason to keep detailed comments on internal limitations in __doc__, can be made into normal code-comment for people who read the source.

You're absolutely right -- not the first time I've been bitten by this inconsistency (dict.get('key') is a similar function, which does have an implicit None as 2nd parameter).

How do you get the active pose-bone from the object? There is no mention of any active pose bone in the documentation for Object, Pose, or PoseBone.

Given that an explicit bl_description is set, is there any downside to keeping the docstring this descriptive? When it comes to a description as to the behaviour of the function/class, I'm in favour of keeping it in the docstring (where it can be shown in an IDE as tooltip, or in generated documentation), rather than code comments.