Well, I only skimmed over the postings made on the devel list.
But overall, I strongly agree with Thorsten and Richard that from a Canvas standpoint there really isn't too much missing to pull that off.
However, David, Heiko and others concerned about the work ahead (and the resulting performance) are also correct - and that is backed up by a number of Canvas-related contributions that either "suck" from a performance standpoint or due to the way the code is structured, i.e. implementations that are insufficiently generic, and those introducing too much Nasal code for things that should be handled by core code.
With that being said, as long as there is core developer support (as suggested and offered by Stuart), none of this would be difficult to tackle. However, as things are standing, we've seen little support (or even just feedback) regarding Canvas related feature requests from core developers, even if those feature requests included C++ patches.
As has been said already on the devel list, the lowest hanging fruit would be using an external simulator/emulator and hooking that up to fgfs - and even in that scenario, the Canvas system would be able to serve as the integration mechanism, because we could fetch a texture from an external process and stream that "live" - we do have various snippets of code doing something along those lines. And that is in fact also how the Garmin GNS430/530 simulators are hooked to FSX/X-Plane - the "trainer" (freely available) is executed separately, the image transcoded and injected into the simulator, with relevant events dispatched to the trainer, and data structures exchanged between the sim and and the trainer executables - and that is actually extensively covered in the FG devel list archives, as well as in the forum archives.
Anyway, like Thorsten and Richard said, the MFD framework that Richard created could (and arguably should) probably be used as the foundation for modeling more complex avionics. However, based on refactoring the NavDisplay framework, we should really consider making this a first class concept at the Canvas level, e.g. by sub-classing Canvas::Element and Canvas::Group to directly implement elements for wrapping MFD related functionality for things like "screens", "pages", "page elements" but also "buttons", "switches" and "modes".
That in and of itself would help make things much more intuitive for people less experienced with Nasal/Canvas internals - while Thorsten and Richard are correct in saying that it's feasible to create such avionics using the Canvas system, it really does require tons of expertise/experience doing this sort of coding - otherwise, Heiko and others are absolutely correct in saying that we do have too many examples of Canvas-based avionics that may look super nice, but that are using naive approaches to implement the corresponding functonality - just like Thorsten suggested previously, and obviously naive implementations written in Nasal are obviously slower than naive C++ code.
Thus, my suggestion would be not to argue with folks are basically saying the same thing by pointing out how many examples of poorly-structured Nasal/Canvas code we already have that really eat up performance, but instead look at what people are really saying, and find a way to "have our cake and eat it".
Like Stuart said, it would seem best to identify what is missing in terms of building blocks that would allow people to come up with sophisticated avionics, ideally using C++ hooks instead of scripting space workarounds.
Apart from that, it also seems that many participants in that discussion are unaware of all the functionality we've got already - such as the WXR/wxradar MapStructure layer that Thorsten briefly mentioned - and it using the MapStructure MVC layer, it is also available to any avoinics using that backend, such as any of the Boeing/Airbus airliners using Gijs' ND - in fact, once you disable "Advanced Weather", you will see that in action:
Besides, there's also other experimental work to implement a WXR controller for other data sources, such as omega95's work shown below:
Overall, I am not convinced that there's too much missing to implement arbitrarily complex avionics on top of the Canvas system and the route manager - however, I am also not convinced that this should be "just done" using tons of Nasal hacks - what is really needed is a team of folks to determine missing functionality, i.e. anything requiring custom Nasal code, that would be best provided as an API - or in the case of performance-critical code, re-implemented at the Canvas::Element level. Otherwise, we're just going to see more and more problematic Canvas/Nasal based contributions that will complicate the lives of people wanting to see better fgfs performance, and less Nasal running in the main loop.
Like I said previously, we can certainly accomplish that, but that would require a willingness among core developers and Canvas contributors to actually work out the details to make that happen, rather than continue working in different camps, without much/any concern for the other camp (school of thought).
What's been happening since TheTom stopped maintaining the Canvas system is that we've grown a backlog of feature requests, and C++ patches, that never got reviewed or integrated - and most Canvas developers simply go on doing their things without much concern for what core developers consider "best practices" obviously, so that -depending on whom you're asking- Canvas and Nasal are definitely causing more problems than they're solving right now ... which is unfortunate.
For the time being however, Thorsten is right - one of the lowest hanging fruits is optimizing property tree access, as in 1) avoiding it whenever possible and 2) making it much faster. The former can be accomplished by encoding update semantics at the Canvas::Element level, so that the element knows when to update an element (per frame, on write, on update, on change, per timer etc) - that alone, would help us get rid of tons of Nasal code. And the latter (making property I/O faster) would basically entail reviewing api.nas to get rid of calls ending up in props.nas, which is to say that we should probably consider porting props.nas to use native C++ code (using cppbind), or at least provide an alternate/faster scheme to avoid props.nas optionally.
These two changes would be fairly self-contained, and they would not involve much in terms of OSG/rendering expertise - it's mainly about understanding the property tree and making sure that update semantics are exposed at the property level, while reducing unnecessary Nasal use. And obviously, providing an alternative to props.nas would also benefit other non-Canvas use-cases where the property tree could be the bottleneck (I think Thorsten mentioned a few AW related instances ?).
Looking at the way we have come to use the Canvas system, and how it adds to the problems that Nasal is known to contribute to, it is kinda unfortunate to see how many useful C++ data structures and helpers are available in SimGear, that the Canvas system cannot use currently - as in having to use various more or less complex Nasal callbacks to implement support for animating Canvas elements using listeners and timers, instead of being able to use Torsten's property rules and/or James's state machine code (both implemented in C++) to do these things.
As far as I am concerned I don't think there's much/anything missing to implement fairly sophisticated avionics using the Canvas and the route manager, but I really doubt that we want to proceed "as is", without having endorsement from the core developer community to actually review opportunities to get rid of some of the more common, and more problematic, instances where Nasal scripting must currently be used to actually add functionality to a MFD - there really is tons of performance sacrificed that way currently, because people are unaware of what's going on behind the scenes (e.g. props.nas being used as the back-end by api.nas), which goes to show why people like Thorsten and Richard are able to come up with sophisticated Canvas based contributions, whereas most other contributors (including a few core developers) tend to use inefficient coding patterns.
In summary, I am not sure if many Canvas developers are even aware of the currently ongoing discussion - because there seems to be a certain disparity between those using the forum and those using the devel list - but maybe, for the sake of the effort, it would be a good idea to come up with a wiki page to actually document what we know, add open questions and volunteers interested in helping with some of the work that lies ahead ?
Like I said, there's at least a handful of Canvas related C++ patches floating around here, including work like Gijs' C++ patch that got added to the hard-coded map dialog, but that never got integrated with the Canvas::Map projection handling code, so that certain performance issues persist, despite the fact that they've been solved years ago - this is obviously unfortunate and unnecessary.
Equally, the route manager/autopilot subsystems are increasingly ignored by aircraft developers, because feature requests were not honored, so that aircraft developers tend to re-implement such systems in Nasal space - which also adds a bunch of problems to the work that lies ahead.
Therefore, if anybody around here is serious about all this, it would seem like an excellent idea to interface between the forum and the devel list, so that we can come up with a wiki page covering what we can do right now, what may be missing, and what may need to be optimized.
Personally, based on my own familiarity with the Nasal and Canvas subsystems, as well as the MFD framework, I am not convinced that we should simply proceed, without providing encapsulated building blocks that can be easily wrapped/re-implemented using C++ level helpers, so that we can easily get rid of bottlenecks, without having to review/rewrite tons of Nasal/Canvas code.