Drivers breaking down after model transformation I am currently modelling a complicated gearbox and I am using drivers to model the relations between the parts. There are multiple gears turning in different ratios and to each gear, a few parts are attached. I used drivers to couple the rotation ratios of the gears and then parented all parts that turn with the gears to those respective gears. The rotational axis of all gears are in the y-direction. This all works completely and looks great. However, if I rotate the model around the z axis for 90 degrees, all rotations glitch at a certain point and jump for a few degrees.
The really weird thing is, if I rotate the model 90 degrees in 5 degree increments at a time, everything is back to normal again and the model works in every direction.
Is this some kind of weird glitch? Is this a known bug?
Is there anything I can do to fix it?
Minimal example
Bad choice of WORLD space.
To test Added a simple driver #frame - 1 to the drive shaft to get it spinning.
As suspected the issues are caused by a
i) Using rotation transform driver type, with WORLD_SPACE

Parented the whole set up to an empty, rotating the world space of the parent changes the world space of the children and causes irregular results.
Recommend either. Lesser
Change all to local space.  Here is a script to select all parts and will change transform  type driver targets to local space.
import bpy
context = bpy.context

for ob in context.selected_objects:
    if not ob.animation_data:
        continue
    for d in ob.animation_data.drivers:
        for v in d.driver.variables:
            if v.type == 'TRANSFORMS':
                for t in v.targets:
                    t.transform_space = 'LOCAL_SPACE'

After which

Note The outer gear is driven by the stationary  hidden object, No idea why it worked at all.
However as mentioned in comments Eulers are prone to gimbal lock and since it's local could simply use the property.  (Also makes sure the rotation is not restricted to (-180. 180) which can be the case in constraints and can be difficult to diagnose if not aware)
Finally, would contend that all gears could be driven directly by the rotation of the drive shaft. For most cases a custom property &quot;drive&quot; could be added to the gear and the driver could be
self[&quot;ratio&quot;] * drive

where drive is a single property variable pointing to the shaft Y rotation, or in the case shown (enable Use Self in the driver)
self[&quot;ratio&quot;} * (frame - 1)

since I set that as the drive shaft Y rotation.