So, structure your project that you can either use the internal PRU or an external motor controller… I don't see the big problem.
I'd say that most embedded related projects will have to deal with newer revisions of their hardware, maybe because an older part is no longer available or because people came up with more intelligent or less buggy circuits over time. So that's already a few (prob. very minor) variations you'll have to support.
And besides very trivial projects, you should always try to have at least one "dummy" implementation of everything, to facilitate automated testing of your code.
So, in your case, yout 3D printer controller could support the internal PRU of the Sitara, an external servo controller, or some dummy library that just logs positions to a file, for testing.
On reflection - you're absolutely right. In fact this is exactly the way OpenGB is designed!
OpenGB uses an abstract base class (called IPrinter) to describe a printer interface. At the moment there exists a Marlin implementation and a Dummy implementation (as you describe) of IPrinter.
Other comments mention BeagleG and MachineKit. It should be pretty trivial to add IPrinter implementations of both of these.
I'd say that most embedded related projects will have to deal with newer revisions of their hardware, maybe because an older part is no longer available or because people came up with more intelligent or less buggy circuits over time. So that's already a few (prob. very minor) variations you'll have to support.
And besides very trivial projects, you should always try to have at least one "dummy" implementation of everything, to facilitate automated testing of your code.
So, in your case, yout 3D printer controller could support the internal PRU of the Sitara, an external servo controller, or some dummy library that just logs positions to a file, for testing.