There is the potential possibility of being able to maintain some gtk2 apps for now by building maemo gtk2 and cssu libhildon.

Don't want to hijack thread by talking more about GTK3 stuff, but a lot of the work porting isn't too bad. Renamed classes/functions, GtkVBox/GtkHBox to GtkBox with orientation param. GtkTable to GtkGrid to avoid depreciation. Clutter is a nightmare along the lines of "Oh! Thats depreciated, use this. Oh, but we've replaced that with this. My bad, that's depreciated as well, use this one no one has got round to using yet".

I'm not as interested in maintaining apps though. As you state GTK mobile apps are few and far between. The stock apps (closed) obviously need replacing. MicroB we all know needs work to replace. If we create pure(r) GTK apps, they might get picked up by other projects. My plan has always been to use as many stock/upstream/standard packages as possible, just maintain our UI and let upstream handle as much of the base as possible.

Qt is a different issue that I'm yet to tackle. My ideas dating back to Qt5 talks were to make an external qt module for the custom classes. You've got the GTK/QT comatibility theme so as long as as much GTK stuff uses stock theme rules (ie not hildon specific) it should be able to use stock Qt5. I also have the souce for qmantle2 floating around for a potential experiment of a Lipstick based WM, and a Hildon UI based on a rework of Marxians componenets. Part of the idea here was that Nokia acquired Qt 18 months prior to Maemo/Moblin merger and used it in Harmattan. If this was the direction that they felt they wanted to take Maemo, maybe I should try to honour that instead.