Nah! Kevin O’Connor already stated, licensing or patent issues with using CAN-FD on Klipper wouldn’t be a problem Add support for MCP2518FD for RP2040 based toolboards - Looking for a Dev - #16 by koconnor
He just doesn’t see any particular gain in utilizing CAN-FD on Klipper.
I do! …and RepRap Firmware uses it! Those guys might have a reason.
CAN-FD is much more robust compared to classical CAN 2.0. That is the main benefit. 3D printers produce a lot of noise Noise (electronics) - Wikipedia. When you remember all the unexplained problems with current CAN used now with Klipper, CAN-FD might be the solution! E.g the latest Timer too close random - #2 by Sineos
Klipper already uses candleLight_fw and STM MCUs support FDCAN. Of course it needs to be implemented and I’m not good enough 
No, that’s why it is not compatible to CAN 2.0. By “delicate”, I’m thinking of the robustness of CAN 2.0 compared to CAN-FD.
Be smart and don’t do that. Enjoy the robustness of CAN-FD.
It’s definetly a lot of work! Programming Klipper source code, getting that working on our HW, and debugging on our user’s end! I think it should be a development goal for 2024!