Many features that were originally added by core developers who are no longer actively involved, tend to stagnate sooner or later - if I remember correctly, it was mfranz (Melchior Franz) who came up with style-able GUI themes by mapping PUI attributes to properties - that was many years ago, long before the recent interest in revamping the FlightGear GUI.
For features to survive, they need to be well-documented, come with examples and use-cases, but even active maintenance/oversight may be required once in a while. Given mfranz's departure from FG matters, several of his contributions have suffered quite a bit in the meantime - which can be particularly seen by the quality of Nasal contributions added to $FG_ROOT.
Having been involved in both the Canvas GUI effort and the creation/porting of the map-canvas.xml dialog, let me clarify a few things:
- the Canvas GUI itself doesn't currently support PUI/XML-based styling, it is using a much more flexible styling system based on CSS concepts
- the map-canvas.xml dialog however is a conventional PUI XML dialog with an embedded Canvas widget, so it is trivial to support legacy styles there (as you figured out meanwhile)
- PUI has been proven to be causing performance issues even when just being rendered/shown - so we were hoping to re-implement the map-canvas.xml dialog using a native Canvas dialog
- like Stuart said, there are several overlapping efforts at modernizing FlightGear's GUI (do a forum search for "Qt5" to learn more) - none of those have announced a feasible concept for dealing with the existing plethora of existing legacy dialogs, intended to be used from inside the simulator (same process, same window) - especially long-term maintenance to prevent diverging UI front-ends and different capabilities, i.e. 5+ years from now (just look at the plethora of GUI front-ends supporting different features/platforms).
- the Canvas GUI however can deal with loading existing legacy dialogs by procedurally turning them into canvas widgets, we have seen protoype code doing this sort of thing already - i.e. a "button" or "checkbox" PropertyList element (as per README.gui) is mapped to a factory helper that looks up the corresponding Canvas creation routine - which transparently supports existing GUI files, without them having to be ported/rewritten from scratch manually
- equally, people could keep using the old/familiar markup for just adding simple dialogs
- internally, legacy dialogs are managed using a few fgcommands which can be trivially mapped to Nasal/Canvas space using addCommand() to build Canvas GUI widgets/dialogs procedurally from existing legacy specs
- this is what the original plan used to be, as it was discussed on the devel list in 2012/2013 - so there is a clear plan to handle these use-cases using the original Canvas GUI approach
Meanwhile, some things have changed mainly because of people starting from scratch with very different ideas and concepts - but none of that is generally bad, especially when taking into account that the UI has been de-facto unmaintained for the last 10 years - so these are pretty much "exciting" times for people interested in a modern FG GUI
Equally, we've had long-standing issues like supporting
sim-wide reset/re-init saving/loading flights at run-time or getting rid of having
15+ redundant GUI launchers, and moving to
online/live-deployment of scenery/aircraft and other resources.
All of these issues are currently being addressed - so "change" per se is not generally a bad thing, in fact, you could argue that many of these efforts have been overdue far too long.
In summary, I think you should go ahead and get your changes submitted/committed - simply because the FG community is hugely chaotic and there's usually more disagreement than actual development going on unfortunately - the very instant someone comes up with with a new feature/idea or piece of code, there are suddenly 20+ people who all remembered how to "design" things properly from their CS 101 days in college ... so, people have a tendency to disagree with something long before they have a better alternative available.
From "our" (canvas/Canvas GUI/MapStructure and map-canvas.xml) side, I can only re-iterate that the mid-term idea was to replace map-canvas.xml using a native Canvas dialog instead (no PUI at all, and no legacy styling, but full Canvas UI styling instead) - mainly because PUI has been demonstrated to cause considerable frame spacing issues even with just the menubar shown, while Canvas performs much better.
Concerning the other two UI efforts going on (web UI and Qt5), there remains one issue that need to be addressed in order for either of those to be considered a viable alternative/replacement for PUI or the Canvas UI (a GUI running inside the main FG process/window):
dependencies i.e. accepting WebKit, and especially, Qt5, as build-time dependencies for all platforms would need to be thoroughly discussed on the devel list to arrive at some consensus. And looking at how divided the FG community was in early 2006 when Mathias started adding OSG, or when Tim started adding boost - it is foreseeable that consensus will be hard to establish ...
In the meantime, you can be pretty sure that PUI is going stay around as long as the Canvas UI isn't yet sufficiently complete, at which point it would be phased out probably, but transparently so - i.e. providing a scripting space framework to maintain parity with the legacy set of GUI files, including dialogs, widgets and styles.