It seems like the issue you're experiencing is related to the way transform constraints and bone hierarchies interact. When you apply a transform constraint to a bone, it modifies the bone's transform based on the target bone, which can override the natural movement of the bone within its hierarchy. In your case, the "sync with L" bone is constrained to follow the "L" bone, but this constraint might be overriding the natural orbiting movement caused by the parent bone's rotation.

To achieve the desired behavior where "sync with L" follows the "L" bone's movement while also orbiting with the parent, you might need to adjust the constraint settings or hierarchy. One approach could be to ensure that the transform constraint is set to only affect certain properties (e.g., translation) and not others (e.g., rotation), allowing the bone to inherit rotation from its parent. Additionally, ensure that the constraint order is correct, as constraints are applied in sequence, and the order can affect the final outcome.

If these adjustments don't resolve the issue, consider using a combination of constraints or additional bones to achieve the desired effect. For example, you could use an intermediary bone that inherits the rotation from the parent and then apply the transform constraint to this intermediary bone to follow the "L" bone.

To add to what Spinebot said, you may need to combine this with the local and relative checks, but I'm not completely sure I understood your objective without a clear visualization.
Yuo may know that if you set a constraint to 100% mix of a property, it will completely override the constraints applied before it, so it may cause an interference.
More about it here:
https://esotericsoftware.com/spine-constraints
If trying these solves your problem, super! If not, if you could please go more in detail in your request, it would help immensely in trying to understand, thank you!

yang123456789 This case is very interesting. I have found a way that would probably work as a workaround, but it would require two transform constraints. The behavior is shown in the video below:

In this rig, a bone Target is added that is at the exact same coordinates as the L bone but moves via a transform constraint, and the Sync with L bone moves with this target bone as its own transform constraint target. It is a bit complicated, but with this rig, the resulting Sync with L bone will move according to the movement of the L bone.

The reason I came up with this workaround is that when I set the target bone for the transform constraint in Sync with L to the L bone, the constraint seemed to be applied to the Sync with L bone before the result of the position change of the L bone was received. Then I thought it would work if I created a bone that would receive the result of the move and set it as the target. Technically, I think it has to do with the timing of the calculation of the bone's world transformation, as explained in the manual: https://esotericsoftware.com/spine-constraints#Bone-transforms

The Spine project shown in the video is here:

It may not be a very clean solution, but I hope it is helpful.