This discussion took off nicely.
My motivation was another thread (Pruning and quality control for the package ecosystem - #13 by Tamas_Papp). I believe, as do others on that thread, that organizations might be a natural and effective way of ensuring quality of packages. An organization might develop a sort of multi-mind intelligence and memory.
I don’t think there’s any real reason for the packages in an organization to comply with a single API or a design principle.
For instance, for time- (or parameter-) independent BVPs (boundary value problems) there’s no reason why they should have an API usable from within IVP (ODE) solvers. Similarly time-space methods will have no need of the method of lines, and so on.
I do agree that if I have a particular BVP and I want to apply two different packages to its solution, it would be nice if the problem could be defined just once and the backend (the solution package) could be chosen on the fly. But that sort of thing is probably best left to the individual developers within an organization…