Grab the Empty named Source (shaped like a Cube) 2.5 meters along X axis. Empty named Destination is properly rotated (like in Transformation Constraint - ranging from 0 to 2.5 rotates Destination -45 Degrees. Here all the fun begins, grab the Empty named Source again 2.5 meters along X axis and look wthat's happening. Empty named Destination should move 1 meter along Local Z axis as set in Transformation Constraint (Space Local Space <-> Local Space). As you can see Empty named Destination move 1 meter in Global Space instead of Local.
Closed, InvalidPublicTransformation Constraint
Imho, this is not a bug, this is how constraints work (all constraints, not only Transformation one): they are always evaluated based on original (unconstrained) object's space – even though this might look un-intuitive…
Assigning to Joshua to see what he says about it. ;)
Ton is right. All constraints always use the result of the previous constraints, and map these transforms into the relevant spaces.
Hence, in this case, we're really looking at how "local space" is defined for objects.
* If there is a parent, we just remove the parent influence. That should now be "local" as in relative to parent.
* With no parent: Because object's don't have a "rest pose" that we can simply use as the baseline to remove from the transforms, we remove the rotation specified by the user via rotation properties (which get set using transform tools and/or buttons). This is used instead of all the rotations currently present (from previous constraints in stack) so that there's still some rotation component left to play with for some of the other constraints (e.g. for limit rotation or so, which would be completely useless).
What this case shows though is that users in some cases do want to be able to have it just take out all rotations.