Things like System Menus, LLM tools and audio effects should be extendible in userspace for a moldable system. I have done this pattern a few times where functionality provider inject themselves into a reactive variable by the service provider, but it does mean they need a direct reference to the plugin host system. This would quite well, until you go full ship of Theseus and rewrite the service notebooks too (which I do). So coupling the other way is a problem too. So I decide to fix this once and for all with a centralized reactive plugin system. So now everybody has a reference to just that notebook, and hopefully it is so simple and domain agnostic that that can last a few years. observablehq.com/@tomlarkworthy/plugin-registry classic service discovery but reactive.

beyond malleability for end-users, setting up a plugin system allows you to safely vibe code prototypes without requiring review. Particularly helpful when you want to get signal from internal dogfooders (maintaining a separate fork tends to not work in my experience) fwiw not all products have a narrow enough interface for this to be easy

SOLID core, vibed shell