Oh, I understand and agree with your analysis. A g-code command in Klipper can not be interrupted by another g-code command.
This was done intentionally, because the alternate would be really confusing for users. As an example, just imagine how confusing it would be if one’s “print start” macro occasionally moved the toolhead to some strange location (because something else decided to run commands at that time). Fundamentally, macros aren’t designed to be interrupted, and it would be really painful to write every macro in such a way that some unknown events could occur between each command.
Just to be clear, Klipper is not constrained to g-code commands. If you use Mainsail or Fluidd (or similar), this should be readily apparent - one can continue to get temperatures and take some actions even while the printer is running commands. Similarly, one can navigate the lcd menus in Klipper even while a command is running (only submitting a new command from the menu is serialized).
It is possible to issue requests to Klipper via the API Server, and those requests are not blocked by g-code commands. This was an intentional design decision when we built the api server, for all the reasons you cite. API server - Klipper documentation
As for changing Klipper so that some g-code can run at the same time as other g-code. Seems a difficult task. G-code is terrible. It’s really hard to use and really hard to understand. In my opinion, it is best to use alternative systems that don’t have the fundamental limitations of g-code.
See also New gcode to interrupt the pending command queue
Cheers,
-Kevin