The onus of not breaking older plugins is on the base app. Here's what I mean:
For example, you expose a Geometry object through an API. In the first version of FAST, subdivision is not supported, so the Geometry object doesn't have a SubdivisionLevel property.

Say, plugin X makes use of the Geometry API, and it works just fine.

THen the next version of FAST is released, this time with subdivision. You'd want to expose this new functionality through an API again. Well, if you change the Geometry API to include a SubdivisionLevel property, plugin X won't work anymore! The new Geometry interface is different from what it expected.

Solution: keep the old Geometry interface, and create a new Geometry2.0 interface that incorporates everything from the old interface and adds new properties and methods.

The risk, of course, is API bloat. But as far as I know, it's the only way of maintaining compatibility with existing plugins.
When releasing a new major version, you could opt to scrap the older interfaces. Older plugins won't work anymore, but then again, I don't expect a plugin that was written for version 1.0 to still work in version 4.0, for example. Backwards compatibility should only go so far.

Clearly, D|S doesn't work this way, else the "broken plugin" problem wouldn't be so ubiquitous. There seems to be no backwards compatibility at all.

The pen is mightier than the sword. But if you literally want to have some impact, use a typewriter

My gallery   My freestuff