Well, we did have a long discussion about Qt5 which covered most points (do a forum search for "Qt5" if you want to learn more).
The thing is, the whole step is long overdue - and for FG it is a huge improvement. FlightGear has become a fairly sizable code base, with tons of legacy code, while making very little use of modern frameworks/libraries. Accepting Qt5 as a general dependency would be a huge shift in thinking, and it could help improve/modernize the FG architecture significantly.
However, it's a tedious process, too - i.e. updating all the legacy code accordingly and getting rid of old cruft in the process.
And so far, there's only a single core developer pursuing this. And looking back in time, we've seen similar efforts that ultimately turned out to be too tedious to be accepted by the wider communtiy of contributors, so that such efforts would ultimately turn out to be merely "experiments" - and "iterations" of a process to arrive at a completely different solution.
Regarding the run-time GUI, that stuff is currently being prototyped - so we will see how this evolves.
The thing is, Canvas is hardware-accelerated and works pretty well - but it is also entirely "custom", i.e. a niche solution - not unlike Nasal scripting, and not unlike the package manager currently being developed. FlightGear already contains tons of half-baked "custom" solutions all over the place, which more often than not meant a "technology lock-in" for the remaining team of active core developers - because people tend to believe in hugely different approaches and technology stacks.
Overall, Canvas -and even the new mongoose/httpd web GUI (Phi)- almost certainly would not have been implemented, had Qt been accepted as a dependency years ago.
And FG as a whole is a legacy code base that contains so many components that would frankly be obsolete by accepted Qt5 now - but this could also provide a "chance for change".
Maintenance is generally a no-brainer once you adopt an industry standard like Qt5 or OpenSceneGraph.
In fact, had a language like Perl, Python or Lua been used instead of Nasal for FG scripting, we would not be having certain issues right now.
Regarding Canvas vs. Qt5 in particular: it really depends on what you have in mind - Anything solely Canvas-based can also be "recursively" supported, i.e. dialogs showing instruments or vice versa - equally, dialogs could show HUDs, while HUDs could show dialogs and so on. Accepting Qt5 as an official build time dependency could provide plenty of options, but would be akin to using a Ferrari sports car to patch up your VW beetle ... and especially people familiar with C++ coding will be quite aware of the impact Qt has, i.e. it being easily much more complex than FG as a whole.
Then again, there are overlapping efforts - the Aircraft Center is entirely Canvas based and could be trivially extended to also provide the exact same functionality that the Qt5 launcher is now providing - in fact, we have seen patches doing exactly that - and the very core developer who is now working on Qt5 support, was also contemplating to use Nasal/Canvas for these purposes:
http://wiki.flightgear.org/Initializing_Nasal_earlyIn the long term, FG would be better off by being modernized through accepting dependencies like Qt5, even though this may certainly be a major inconvenience for other contributors - not unlike the original OSG port/migration in early 2006 was. In the mid-term, it isn't unlikely that Qt5 "inclusion" will be up for debate - even if all active core developers would spend 90% of their time working out how to integrate Qt5 into FG, we would still only be using a tiny fraction of Qt in FG, while still requiring the whole shebang to be installed/built for compilation.
Regarding fgrun: tools like "optirun" don't have any impact on fgrun's memory occupancy while fgfs is running, so memory used there won't be available to fgfs