yeah, 3.2 will contain all relevant changes that you can see in the canvas-hackers clone - there are just a few branches that contain "WIP" code that won't be included, but you guys haven't used any of those modules as far as I can see.
Also, don't worry: we've got another 6 months now to add new features because 3.2 is going to be out soon - so plenty of time to review new code and features and integrate them properly. And as long as you guys keep reviewing your own code mutually, you should be all set - omega95 seems to be able to flesh out new features very quickly, while artix seems to have mastered advanced Nasal/MapStructure basics pretty quickly - so you guys should be fine as long as you keep coding with a generic mindset, i.e. to support use-cases like:
- multiple independent instances per instrument/layer
- different instruments/aircraft (i.e. with different AP/RM or NAV/COM dependencies)
- the GUI use-case (see map-canvas.xml in $FG_ROOT/gui/dialogs)
- styling (custom colors, fonts, symbols etc)
- different position sources (aircraftpos.controller/NDSourceDriver)
None of this is rocket science or even very difficult - these are fairly basic things, but most people fail to keep all of them in mind, so that they end up coming up with instruments that only support a single use-case unfortunately.
But as long as people keep following a handful of guidelines, we can even easily support new use-cases, including even a standalone FGCanvas mode, without it involving a ton of porting work. Likewise, GUI dialogs for configuring weather or showing a GUI console, would then automatically be able to also support holding patterns, vertical profiles (VSD) and weather overlays.
And you really only need to know a subset of Nasal to apply these guidelines, and it will get you pretty far.
The main feat of the ND framework, and even MapStructure, is not so much its design (sorry, P.
) - which isn't particularly "standard" or even elegant - the main accomplishment is its loose coupling, i.e. the decoupled nature of these modules makes it possible for people -who are interested in very different aircraft, avionics and use-cases, to still collaborate effectively, simply because things are so flexible. So these two "frameworks" are primarily collaboration enablers, because people that would normally not collaborate can all of a sudden easily work on a common code-base pretty easily.
People doing modern MFD-style avionics or any kind of mapping/charting displays should really have no reason NOT to use these frameworks - if something is missing, extending the framework is simple enough, and it means that your work is going to be used -and even maintained- by a number of contributors who have a track record doing similar stuff.
Obviously, there are quite a few other examples of great avionics developed in Nasal/Canvas, particularly the Avidyne Entegra R9 - but as long as those are non-generic and use-case specific (e.g. single aircraft), it is unlikely that fellow contributors will step up to help maintain such modules over time unfortunately. And re-implementing existing instruments on top of NavDisplay/MapStructure is a win/win for all parties involved, because there's less aircraft-specific code involved at some point.
The whole MVC separation established by the ND/MS frameworks allows people to collaborate despite possibly working with very different aircraft and instruments/avionics, which even includes people who don't do any aircraft/instrument development at all, but "merely" GUI dialogs like an instructor console for example.
FlightGear Forum
So my work will be a bit slow during August 
