Report as inappropriate

I guess you're right.
I browsed the Marlin 2.0 code just minutes ago and I'd say, it looks very promising. It's pretty modular and at first glance I think it doesn't need many changes.

I looked at the 'feature' folder and especially the Prusa_MMU2 feature (https://github.com/bigtreetech/BIGTREETECH-SKR-V1.1/blob/master/firmware/Marlin-bugfix-2.0.x-SKR%20V1.1/Marlin/src/feature/prusa_MMU2/mmu2.cpp).

The cleanest approach would be to create a new feature, let's say '/feature/SMUFF/' and add files SMUFF.cpp / SMUFF.h to it, whereas SMUFF.cpp needs to implement the public function SMUFF::toolChange(uint8_t index) (at least, don't know what else Marlin 2.0 needs for interfacing).
Then, the module toolChange.cpp (https://github.com/bigtreetech/BIGTREETECH-SKR-V1.1/blob/master/firmware/Marlin-bugfix-2.0.x-SKR%20V1.1/Marlin/src/module/tool_change.cpp) needs to be extended like this:

  #include "../feature/SMUFF/SMUFF.h"

and somewhere in the toolChange function itself:

    UNUSED(fr_mm_s); UNUSED(no_move);


And of course, somewhere in the code the 'smuff' instance has to be created and the serial interface has to be defined as well.

The not so clean approach would be to adopt the SMUFF GCode parser to interpret the commands sent by the Prusa MMU2 and act accordingly.

Either way... code must be changed / extended but at least it's doable and - as it seems to me - with less effort then in the Marlin 1.x.
One major culprit of Marlin 1.x is the non existing second serial port for communication, which has been added in 2.0 apparently.