I like your approach (This fork starts from upstream Klipper and vendors Beacon into the tree so that Beacon can support multiple configured sensors without forcing every workflow to address them with SENSOR= every time. Klipper-Modifications/docs/tinman_multi_beacon.md at tinman/dual-z-probe · Tinman-FP/Klipper-Modifications · GitHub ) to implement two z probes in Klipper.
I guess your klippy.log is dirty, which brings me back to New proposal for Klipper "extension" support .
Does anybody know if there is any development for an easy handling of extensions and still being “not dirty” with genuine Klipper?