Oh, nice to hear!
What do you mean by “only on the interface”? We currently provide more than 20 solvers, so I would say that that might be a sign, that we focus on both in equal manners.
One challenge here is, that all interface design and 90% of the solvers are implementation by just myself. The remaining 10% were students of mine (3-4 master theses) – currently for example an ARC solver that should be faster than TR.
for TR and Steinhaug-Toint, that was also a student project and some while ago – definetly not the students fault but also due to my experience in speed, the solver might not be that fast.
And sure, if you compare to ALM or the more recent DC solvers, the trust region one still misses the flexibility that currently the suit solver is not so easy exchangeable. But it would be great to have, for sure to
- make that more flexible that the subsolver can be exchanged (I added an issue here since this hopefully is more like a technical thing)
- implement different solves for the sub problem in trust region (I have no clue about these).
But I have to honestly say that for the next year or so, I do not see much time in my schedule (maybe I can do that with a student project).
Keep in mind that most of that is done in my free time – at least the algorithms I do not do research on myself.
Also – contributions are of course always welcome – I can definelty help with step 1 – but for different sub solvers I would also have to read on them and their efficiency.
edit: Or to be precise – this mechanism of specifying sub solvers was developed last autumn – while the trust region solver with its sub solver was written four years ago. So it can definetly be improved both in flexibility for sub solvers and in speed itself – it is just a time issue on my side. So feel free to help 
edit2: If you have references and can describe what you need – for best of cases with manifold references, feel free to open that as an issue