After some more working around the problem, I’m not so sure this is actually a very useful approach.
My assumption was that the long rotation would prevent hitting joint limits. However, in some cases we actually had to rotate in the same direction as the short path, but an additional 2*pi. I’m not so sure that this can easily be fixed in movel() without making the robot movement rather unpredictable.
So, we did manage to detect what rotation should prevent hitting the wrist3 limit in our setup, but there are a number of assumptions it makes which don’t hold in general. However, once we detect which way we want to rotate, we have to inject multiple movel() commands to force the robot to take a longer path (either alpha - 2*pi or even alpha + 2*pi). This is less than ideal because it is not trivial to come up with a a good blend radius for the waypoints.
So I think a different command might be useful, a command that takes a pose relative to the current TCP pose (moveLR?). Basically instead of describing the desired end pose, you describe the desired motion. Then you can easily make the robot perform a linear rotation in cartesian space of more than 180 degrees without having to worry about blend factors.