It seems you are missing the point, using Nasal code to this degree to implement avionics is rather unfortunate - in a perfect world, such avionics would only be set up from Nasal space, but all the runtime overhead would be handled by native code - so far, we're still making heavy use of timers and listeners, which means that the display code inevitably ends up in scripting space sooner or later, where all/most heuristics are handled.
We realized that this would be a huge issue early on, doing hundreds of getprop() calls without caching them via memoization, would add up unnecessarily. This is how MapStructure came to be, we wanted to create a framework where all the nitty gritty details were encapsulated, so that if/when things turn out to be too slow, we can instrument the code and optimize it accordingly (e.g. by re-implementing portions of it in C++ space).
That way, all front-ends (cockpits/UI dialogs) would automatically benefit from such optimizations.
A number of other teams developing Canvas based avionics ended up arriving at the same conclusion, e.g. look up the comments by the Extra500 team - they stated quite clearly that there were hitting performance issues, so they ended up looking at how MapStructure worked under the hood and re-implemented portions of it in their own code.
Realistically, MapStructure would not be needed at all, if the sc::Element was fully exposed to scripting space, so that new elements can be registered that way - equally, handling display and element animations/updates via timers and listeners is awkward and not a good way to update OSG/OpenGL state.
Also, the Canvas UI system does have styling support via properties (analogous to how Effects support inheritance) - basically, exposing these two, would mean that we'd solve a ton of problems automatically, including even support for multi-instance setups using Canvas avionics (think LinuxTag/FSWeekend-style setups with master/slave configurations, or multiplayer/dual control).
You could also take a look at the shuttle code, it's not using any MapStructure stuff at all - but it's using memoization, via some of Richard's work (property manager).
The thing is, you can argue all day long that generic code is inferior over what you may come up with - but that's not the point at all, the MapStructure stuff was developed to support an arbitrary number of independent "mapping/charting" displays that may be driven by different "drivers" - thus, this was also intended to be a stress-test for the Canvas system, at a time when many of us were still tinkering with Nasal/Canvas for the first time, we were hoping to help shape the API, and we didn't want people to use copy/paste to do their avionics coding, let alone the low-level Canvas API that you are referring to above.
Again, look at Thorsten's shuttle work, even there he ended up adopting higher level management helpers to optimize the system. That's a piece of work, where you have the need to fetch/update hundreds of properties and probably half a dozen of displays shown concurrently, if you screw up the coding there, it will show quickly.
This is why, MapStructure was developed out-of-aircraft, i.e. using just a set of UI dialogs, and drivers to hook up the display to the driver properties (aircraft specific), and that is also why it can handle/show different displays without using any copy/paste.
Conventionally, these sorts of things would have been implemented by copying/pasting the corresponding code and updating it manually, the MapStructure/MVC approach means that aircraft using MapStructure, contribute to the same system.
http://wiki.flightgear.org/Howto:Protot ... play_Style
@lego: excellent job troubleshooting this, and thanks for explaining to others where the real problem lies, instead of pointing at something entirely unrelated like the MapStructure code.