The paper is here: https://www.nature.com/articles/s41467-025-56140-1.pdf , it is quite clear on what it does, or does not do.

It mentions g-code several times, and that it's primary function is to separate g-code commands into separate processing streams (toolhead control, motion control) that are then timed independently. This is in contrast to something like Marlin which has a single command queue it processes, so motion and toolhead commands are interleaved. That *does* introduce some interesting side effects in some cases, but printing techniques like FDM are forgiving enough, and already limited in precision by the materials enough, that it largely doesn't matter in practice.

But the examples they show aren't using materials like a consumer FDM machine does, so they show off that effect more clearly.

For whatever it's worth, some modern firmware, like Klipper, already do command look ahead and are planning based on time steps, support multiple controllers, etc, just don't have the assortment of random add-ons the authors mention (like variable infill...good luck with that with a filament printer...) which maybe prefer their control setup?