Note that the issue is two-fold, because FlightGear's scenery depends partially on the navdata - i.e. some aspects of the scenery are statically pre-compiled using a toolchain called "TerraGear", e.g. airports/runways/taxiways.
The other issue is that the corresponding data is hard to get your hands on for most parts of the world (for details, look up the whole history on DAFIFT):
http://wiki.flightgear.org/Dynamic_Airport_GenerationThus, updating navaids is a little more involved than it may appear at first.
In the meantime, a number of long-term contributors and core developers have suggested to procedurally create the corresponding airport/runway geometry at runtime, so that newer/alternate navdata sources can be used - this would also mean that a 3rd party navdb could be used, including even a standalone navdb service (think an online API) - this is something that would also make it possible to properly shut-down certain navaids depending on the selected date/time:
https://sourceforge.net/p/flightgear/ma ... /35383393/I think your use scenario highlights a fundamental problem with our scenery approach, in dealing with historical periods. We just have no good way to have most of the nav data be current, but some portions reflect the world as it was in 1960 or 1980. I would prefer we maintained some global historical data sets of nav data, but in principle this would also mean maintaining historical scenery and airports, and selecting / de-selecting models based on data ranges. (So buildings appear based on their construction / demolition date).
Note that this would also help related efforts, that are currently limited by GPL restrictions (think fgmembers wanting to ship/include proprieary navdata with their aircraft)
See the wiki and the devel list archives for details:
https://sourceforge.net/p/flightgear/ma ... /35377711/