@thinkyhead @marlinfirmware I guess a future development for MarlinFirmware would be to take a leaf from Klipper's book and introduce some code partitioning.
You could e.g. make a split into marlin-driver and marlin-manager where the former handles the machine-specific parts and the latter the higher-level details. The interface between the two parts could be SPI (for co-resident) or USB (for separate) implementations.
This would also permit divergence in implementations in the future with the machine-specific parts being written in an efficient embedded language while the higher-level detail could be re-engineered using whatever is appropriate to the (changing) technology it runs on e.g. Rust or Zig.
@thinkyhead @marlinfirmware That's fine, in principle, but consider that single board controllers with multiple microcontrollers or mixed microcontroller/SoC setups become the standard (primarily driven by Klipper).
It might be wise to adopt the "never say never" philosophy rather than stick with the original project goals which could lead to stagnation of the project.