It' been a year! wow.
Unfortunately, it seems that we won't be able to maintain (engine's) Plugin API in its current form. By saying "not able" I mean it will be
pain in the... head to do so.
What's wrong with current plugin system?
1) It grants free access to internal engine data. Which...
a) allows plugin to easily corrupt engine's memory;
b) prevents from changing internal object implementation;
c) prevents from changing data location in memory (like, dynamic reallocation on new place, which is common when arrays of objects grow or shrink);
2) It is based on classes with virtual inheritance. Which is not so bad on its own, but it appears that different compilers pass class objects slightly different, and that "slightly" is enough to screw things up when there's virtual table pointer in them.
Keeping those points in mind, those are requirements for (engine's) Plugin API:
1. It should not provide addresses (pointers, references) to real engine objects or parts of those objects.
Instead, engine may return interface objects that serve medium between plugin and game object, and, in certain cases, temporary PODs used to
read/write game object's state.
2. It should not have interfaces with virtual functions. This means that interfaces may only have normal functions and member variables.
3. Additionally, we may consider to let people write plugins in C, in which case the only option for interfaces are C structs with function pointers in them.
In fact, unless I forget some other opportunitues, it seems that C-style interfaces (structs with function pointers) are the only option, because if we can't use virtual functions, we won't be able to create extending classes in plugin to pass their objects to engine (like for the font renderer) :-/.