Some time ago @rhaschke resolved an inherent issue with our CurrentStateMonitor and made the waitForCurrentState method actually wait for processed joint state messages that refer to the current time. In order to do so, he used a ros::Time current_state_time_ member that is updated whenever a new joint state is received.

However this poses another inherent problem that still exists in the current implementation:
It assumes that the current message contains information on all joints, which is usually not the case if the hardware setup has more than one component with different hardware drivers.

To workaround this problem, users can remap their joint_states topics and merge them before they are fed into MoveIt, but this is almost never done and adds overhead and a delay.

A solution to this problem probably has to store a timestamp per joint (or joint sets published together) and use the oldest timestamp (possibly within the set of joints of some planning group of interest) to represent the actual current_state_time_.