I hope you're looking carefully at COM/OLE Automation, which achieved pretty much all of those things.
- In-process and cross-process language-agnostic API bindings.
- Elaborate support for marshalling objects and complex datastructures across process boundaries.
- Standardized ways to declare application and document object models that can be used by external applications, or internally by application add-ons.
- A standardized distribution system for application extensions, including opportunities for monetization.
- Standardized tools for binding application APIs to web services and database services.
- A default scripting engine (VBA) that can be embedded into applications.
- Admittedly primitive and mostly ill-advised support for dynamically typed objects, and composable objects.
And it provides opportunities for all of the levels of application customization you seem to be looking for.
- Trivial tiny customizations using in-app VBA.
- The ability to extend your application's behavior using addons downloadable from a marketplace WITHOUT trying to capture a percentage of licensing revenue from those who want to monetize their add-ons.
- The ability to write scripts that move data between the published document object models of various applications (and a variety of standard data formats).
- The ability to write fully custom code that lives within applications and interacts with the UI and with live documents within those application (i.e. write-your-own add-ons).
Plus it would be enormously fun to build the equivalent functionality of COM/OLE with the all the benefits of hindsight, and none of the cruft incurred by Visual Basic, with lessons in hand from some of the things COM didn't do well. (svg as a graphics transport, perhaps? A more organized arrangement of threading model options? Support for asynchronous methods? A standardized event mechanism?)
Questions that come to mind:
- What can you get away with not doing that COM does do? Not much, I think.
- How could you make it better? A bunch of ways!