In simple terms, this is pretty straightforward thanks to the way the MapStructure back-end is designed: Its layers (VOR, DME, FIX, APT) never make any assumptions about their front-end (for example GUI dialog or cockpit instrument) - therefore, all front-end specific stuff is not part of those drawing routines, but it's part of so called "controllers" that are typically 10-15 lines of code (of which only ~5-8 lines need customizing, the rest is typically copy/paste programmming) - that way, you can easily add controllers to support additional avionics.
Consider the image below, the "controller" is the orange box:
For example, let's say we were to come up with an aircraft that has 5 navradios - the only thing required to use those in a ND/MapStructure layer is changing the index number of the radio in the property tree. Now, let's look at one of the controllers that's actually using the navradio, e.g. the DME or VOR layer:
https://gitorious.org/fg/fgdata/source/ ... roller#L20You can see, that this layer will automatically register listeners for ALL navradios
automatically. So that part is already working - the only problem is that you won't see a difference, because all instances work like this at the moment
So this would need to be made configurable so that each layer could handle only certain navradios - that would take 2-3 minutes to change/test and commit, so no big deal
PS: No need to work on this, I can implement that within a few minutes, I just need to pull --rebase my own stuff first, juggling too many branches and starting to get lost ...