It doesn’t sound like a long shot at all. Defects in code tend to hide in places that aren’t used as much as others; backlash compensation could easily be one of these. One kind of failure could be a failure of atomicity in keeping track of compensating movements, either recording a movement then getting interrupted and not doing it, or vice versa doing the movement and not recording it, so doing it again. I did a brief review of the code; all the backlash compensation is in the Marlin code base; I didn’t see any of the Snapmaker code touch it. Most of it’s in planner.cpp.
One thing worth noting. The Marlin code base has an odd option to do backlash compensation over a number of steps rather than a single one. The effect is to smooth the surface of a filament-printed object. It’s not what you’d want for a laser print, though. It looks as though it’s turned off, but if it’s not, it might cause some line shifting and a bit of distortion that would stretch or compress pieces of a line near a direction change. M425 reports the backlash correction parameters.