Folks have been musing along these lines for decades. There have been a few attempts. To date, they've almost all failed. The problem domain here is a lot more complex than anything we'd normally call a "plugin architecture". IMO, the problem is that this sort of interoperability pretty much requires the power of a full-on programming environment. If it's even possible, I think it also requires an architectural organization that no one's yet divined.

The notable successes tend to be domain-specific and manifest as end-user programming environments. The spreadsheet might be considered a weak example of this. It has a clear user model that allows for powerful extensibility, but doesn't really facilitate "interoperability" in any meaningful way -- each spreadsheet tends to be a one-off.

The Max/MSP (and Pure Data/Pd) environments for audio/visual signal and event processing are perhaps more successful in that they allow the simultaneous construction of UI and logic in a visual programming environment. A program (aka "patch") can be built as a reusable sub-program that manifests the same kind of interface as the primitive (native-code) modules. But again, this is another narrow domain application with a specific visual-semantic model which works well for that domain. That contrasts to the OP's problem of adding arbitrary UI to a software whose main domain has nothing inherently to do with either the added UI or even to programming.

I'd also say that the venerable programmable programmer's editors, Emacs and Vim, form another category of end-user programming environment with loose interoperable modules. These are certainly subject to a fairly high degree of extensibility within their domains. But these are saddled by frustrating UI constraints and architectural models inherited from their now ancient origins. Interoperability between "modules", such as it is, is largely ad-hoc and far from guaranteed.

Each of these successes can teach us something about what works for these kind of programmable-framework environments. But to achieve The One Architecture To Rule Them All goes beyond simply having the tools of design, architecture, language, and environment. It must also become a computing platform, where by "platform" I mean an ecosystem that's large enough to have the social synergies that make the above examples and other conventional software platforms successful.

> To date, they've almost all failed.

Eclipse is an example of an immensely successful plug-in architecture-based software.

It's amazing how well plug-in ecosystem in Eclipse operates. For instance, I could install the PyDev plug-in and have an intelligent Python editor -- but at the same time the EGit plug-in provides seamless git integration that works with any language!

How all these plug-ins come together and play nice with each other to create a cohesive and powerful IDE is impressive!

... we have that, it's called dynamic linking.

Much more than that, and you're back at the start. In this case, the plugin would need to interop with the app to pickup internal UI states (dragging a selection rectangle, versus just moving an item) and interface with that coordinate system.

I'm curious how you think you'd have "interoperable modules" that would provide such functionality, without creating a large framework to specify all this stuff in the first place.

> …without creating a large framework to specify all this stuff in the first place.

It is, in most cases, significantly more work to create a plugin architecture that could allow for some feature to be implemented than it would be to implement that feature statically — and most of that extra work is not shared.

Until you lose users because implementing that plugin infrastructure slows down your program or prevents certain features from being written easily (either directly due to trade offs in having the infrastructure implemented or indirectly in not wanting to break compatibility with older plugins).

Also as Apple showed, a nice polished product sells and that final polish matters. It's a lot more difficult to do that when you need to deal with an unknown quality like plugins.

But then you have the new problems of what plugins to include by default, how users discover plugins and how they are configured.

Plugins, while valuable for people willing to take the time to learn about your product's eco-system are unlikely to help users who are willing to spend only 5 minutes evaluating your product.