Yep, we’re talking about the same thing. In the case of grbl, Marlin, TinyG, etc, that’s embedded in the product. In an industrial system, it would be a separate component called a “Motion Controller”. Some products such as the Parker “PAC” can be loaded with different kinematic models and it will solve the kinematics and disburse movement commands to each separate servo amplifier. The servo amp executes the move, and reports its position/velocity/acceleration back to the motion controller. The servo amplifier itself isn’t “aware” of the other motors, it simply responds to commands from the motion controller, which is itself responding to an End Effector position/velocity/acceleration command from the PLC or computer, etc.
See Thoughts on ODrive Architecture for my thoughts on ODrive’s possible architecture for handling this. TL;DR: I envision it as 3 separate modules, the PLC, the Motion Controller, and the Servo Amp. Each module could be enabled or disabled in software. If you want it to behave like a 3D printer controller, you enable all the modules and it’ll be just like using Smoothie (or something similar). If you want to just use ODrive as a powerful, inexpensive servo driver, then disable the PLC and Motion Controller modules.