a plugin's registrations returning individual cleanup handlers is nice. in pi, you clean up all registrations in one go in the session-shutdown handler.

i also like the use of generator to to clean up partial registrations nicely.

the cross-plugin dependency injection and resolution i'm not so sure about. it comes with a lot of footguns and limitations as pointed out in the paper.

works ok within a single compilation unit, i.e. a plugin with many modules. does not help with typing of cross-plugin dependencies.

most plugins do not have dependencies on each other, so this more complex system doesn't win you much, e.g. with load order and conflicting registrations (i.e. two plugins registering the same tool).

being able to reload a single plugin on change while letting the others not in its dependents list jug along is neat. but that also only works if plugins actually declare dependencies (see last paragraph), and also has a lot of limitations. and the simple case, a plugin with no dependencies or dependents, which i'd say is the 90% case, does 't need that complexity either.

definitely cool stuff tho! remains to be seen how well it works in a real plugin ecosystem.

> they push the boundaries further, to the UI components

can you elaborate on this? pi extensions support contributions to the UI. in pi v1, they are limited to in-process UI. v2 splits server and client, and with that UI.

Yep sounds just like the Eclipse IDE plugin system indeed. Nice example of things being rediscovered every generation I suppose.

That actually sounds amazing.

If anybody has tried it, does it let you preview components in any frontend framework with perfect fidelity? That would be a big win.