In the last couple of years, FlightGear has basically never really been able to reliably switch different aircraft at runtime, so that users need to exit FlightGear in order to change the active aircraft.
This problem is mainly due to architectural shortcomings in the original init/loading code that -at least in part- even dates back to a time when FlightGear was still very new, not surprisingly said code is now facing tremendous challenges when it comes to providing support to the many new features that have been added to FlightGear since then, and which more often than not complicate the housekeeping process required to properly retain and manage session information in order to be able to return to an arbitrary state.
While having to quit/restart FlightGear in order to switch aircraft is mainly a matter of inconvenience , this issue and the fact that it has been around for so many years meanwhile, also illustrates technical low-level limitations in the underlying core code that apparently could not be solved in the last couple of years.
The Status Quo:
Basically, FlightGear -in it's current form- doesn't really have any sort of concept about "sessions", rather the closest thing to "session support" consists currently of simply dumping initial state (property tree) to a temporary variable, so that it may later on be used to regain said state in order to -hopefully- reset the FlightGear core to a usable state, where new data may be dropped into the tree.
However, due to the aforementioned wealth of new features in FlightGear (often, interacting with eachother in many not-easily predictable ways), this attempt to approaching FlightGear sessions, is not only overly simplistic but also pretty error-prone, as it may yield hard-to-reproduce issues (i.e. because of all sorts of data/code leftovers from previous sessions possibly affecting the new session).