Plugins that break when a newer version of the base app is released.
Yup, that's a major pain in various body parts. Preventing it from happening is quite hard to do, but at the very minimum it requires a very wel thought out set of APIs for the base app THAT DOES NOT CHANGE WITH EACH VERSION. And if new functionality is incorporated into the base app, a new API should be added to the existing one(s), in order not to break existing apps that use the older API.
It's not unlike the infamous COM DLL Hell. I've programmed COM components and it can be done right, but that requires self discipline on the part of the developer. You have to stick to the COM versioning rules, and there's nothing in the development enviroment that prevents you from deviating from those rules.
Microsoft itself breaks its own COM versioning rules on a regular basis (ADO2.1 apps break when ADO2.5 gets installed, which should not have happened). Can be very frustrating.

The only way to make an app stable for plugins is by freezing APIs. A new set of APIs would mean a new major version number, minor version upgrades should not change existing APIs. 
Even better, a new major version would/could have new APIs in addition to the unchanged existing ones from the previous versino, so that plugins written for FAST 1.x would still work in 2.x and up.

I like the Linux version numbering system: odd minor release numbers are "test" releases, that introduce new functionality, even numbered minor releases are stable releases. Revision numbers and build numbers would be reserved for fixes/patches. It's a well known system, and as such it would make it easier for users to understand the FAST versioning scheme.

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

My gallery   My freestuff