by Hooray » Fri Jan 02, 2015 5:35 pm
The other issue here being that for for an older binary (think 3.0) to work with aircraft for 3.2+, the updated aircraft needs to be specifically developed with backward compatibility in mind, which is very rarely the case given the added manpower requirements - there are a few role models on doing this properly, such as the bluebird for example - but otherwise, most aircraft really only target a single version, and rarely, if ever, provide different -set.xml files for different FG versions - in addition, FlightGear itself isn't internally structured with a focus on backward compatibility, which doesn't just apply to 99% of the fgdata resources, but also most of the c++/core code.
For instance, the recent route manager changes are implemented in a hard-coded fashion (for reasons that elude me completely...), so that it will be next to impossible to override/customize or update any related logic short of updating the whole fgfs binary itself - and the way aircraft updates have been applied to respond to these changes, updated aircraft like the 777 won't work as well with older binaries any longer, because there's the implicit assumption that the latest binary will be used (or even git/next).
The hard-coded route manager in particular has been known to be a problematic/unstable feature among many aircraft developers causing a lot of frustration, up to a point where /some/ aircraft developers would go as far as re-implementing the whole system in scripting space just to be on the safe side, and just to be able to implement custom functionality, without being restricted by core development.
In other words, it is technically very well possible to allow aircraft/scenery and navdata to be downloaded/updated on the fly -but actually applying/using these resources requires a shift in thinking that seems very unlikely to happen anytime soon.