As it is in 5.08 at least and probably 5.09. I think I might know what the thinking was and how the reversal bug was born, and maybe why it hasn't (from what I hear) squashed yet.
Word from Logitech has been that it is just part of making sure the thing is less nervous, so that is what the intentions were and what part of the code the reversal bug belongs to. But the behavior we see is (enormously) detrimental to the stated intention - the exact opposite of what it was supposed to do.
They probably intended to put in a 'numb' area of physical movement required of axis movement in the opposite direction until it actually registered, and the output sent would accurately never make any jumps but only start to move from the last position slowly in the other direction once the axis has physically moved enough in this direction. This would make perfect sense to put in. The jump as we see it (4%) would be a logical size of this numb zone (for the rudders and trims especially) and make the device very well behaved and accurate. The rudder would be gentle, smooth and easy to use even when doing smaller movements. The throttles would stick together much more when moved together, moving small increments and finding the exact spot would be an easy affair. TRIM wheels would be smooth and relaxed. The stick doesn't need this as the hall sensors are pretty damned accurate to begin with (but the added reversal bug jumps takes away the precision currently).
________
Current (5.08, maybe 5.09) Behavior: Gently start to move in the opposite direction = output quickly makes a large jump of 3-4% in the correct direction (far disproportionate to the physical movement). Same happens again when trying to reverse back again to get to the intended position. Over and over.
Analogy: Imagine putting your finger into a glass on top of a slippery table. Your finger is the physical position of the axis. The glass position on the table is the 'output' that is sent to our games etc. When you start moving the finger in the opposite direction, the glass makes a jump the size of its diameter into that direction before your finger even gets to the other side (yeah, it would 'move through' your finger as your finger was already at the edge, but it should help to get some idea).
Intended Behavior: Gently start moving in the opposite direction = at first, no change to output. After moving 3-4% of PHYSICAL travel, the output starts moving gently in the correct direction, from it's last known position.
Analogy: Dragging the glass with your finger in one direction and all is well. When moving the finger into the opposite direction, at first the glass will not move, for the finger has to move from one edge of the glass to the other edge, until it reaches the edge and pushes the glass into the other direction.
________
To make the intended behavior work for them, they would probably tried to do the following:
1. When axis (input, potentiometer/hall sensor etc) is moving into opposite direction, freeze the output where it was last registered.
2. When axis has moved enough distance (3-4%) into this direction, unfreeze the output.
3. Since the axis (input) has moved a sizable distance (3-4% of travel) the output must be adjusted, else the output will just make a 3-4% jump to catch up with the axis. This done by adding or subtracting 3-4% to the output 'position' in the OPPOSITE direction of how the axis is moving. This makes the output just keep going from where it was last positioned without any kind of jitter or jumps.
________
My theory is that they put in step 1. But step 2 is not working. Step 3 is still employed but not only is it employed right away without delay, but also the adding and subtracting values are reversed (i.e. it ends up boosting the movement in the direction rather than retard it).
Together, they produce this totally bizarre jumpy behavior where it makes constant jumps whenever the direction changes and accuracy is impossible without third party software to apply post processing on the output to compensate for the weird jumps.
The good news in all this is that this should be easily corrected in a firmware upgrade.
