Just FYI, it’s not always about compensating hardware shortcomings, but also about achieving best quality in non-typical conditions. My printer has belt-driven Z, with auto-measured ~0.25 mm backlash, and manually measured 0.15 mm X and Y backlash. Pro model from the same manufacturer has a XYZ brick for backlash measurement. 0.25 is almost unnoticeable during normal use, but if I want head-lifting, multi-material switching purge on specific Z, job start-pause, accurate bed-level and so on and so on all while keeping the result in best quality with 0.15 mm or less layers, I need the best precision possible. And Klipper seems to be focused on print quality, so lack of backlash compensation seems a little strange.
Non typical condition are rare by definition, and the limited developer time would be wasted on features few people would use.
However contributions are welcome, assuming enough users are then willing to test them to let the reviewers know that the changes are safe.
Hi. A while back I created a post processing script to add backlash compensation to the gcode, it’s being run on the slicer-end instead of the printer-end, but it should work well in most cases.
I would argue that klipper is not a welcoming place for PRs and contributions. The github is littered with hood ideas and PR effort that is second guessed to death or ignored due to lack of resource.