if someone wants to have a go re-doing the groundtrack map, he's most welcome, the current design is my first (!) canvas experiment and the code is pretty crappy because I didn't know any better.
Stuart recently added a new type of MapStructure layer for overlays - and we do have support for plotting ground tracks (e.g. the flight path history), we could also tell the same drawing routines to render a future state vector - as logn as we pass a vector with positions to it. Which is to say, that it may not be that far-fetched to use the MapStructure system to extend/redo the orbital mode. That would also mean that the display itself would become available to other aircraft, and that it could be added to other charts/displays much more easily.
Regarding saving/loading flights:
I think Thorsten mentioned elsewhere that the shuttle team created their own scripted load/save helpers - otherwise, the replay/flight recorder system (fgtape) would be the most likely candidate - however, it's pre-dating the shuttle by several years, and was considered fragile even for conventional airplanes - so not sure if it's even feasible to consider using that for spacecraft like the shuttle - it may need to be extended to do so.
Apart from that, the real issue is that anything involving computation of values (flight dynamics, autopilot, route manager, scripted systems and so on) must provide a mechanism/interfacing point to deal with resetting its systems to a new state vector - imagine resetting all systems to fly an approach. Basically, there is no sane way to support this in a generic way - aircraft developers must be made aware of what the user is trying to do, so that they can shut down/suspend their systems and re-init everything according to the desired state vector (situation/configuration).
The only thing FlightGear as a platform can do, is provide "signals" and building blocks to encode such state vectors - other than that, this is the primary reason why resetting any aircraft in FlightGear a few times in a row is likely to cause a crash, but also the reason why saving/loading and continuing flights is usually not possible at all.
Basically, each and every subsystem running at any point in time would need a way to respond to a shut-down/reset or save/load "signal" and do internal housekeeping - while this is something that David Megginson (creator of the property tree and subsystemMgr implementation in FlightGear) originally designed, it was never actually used or carefully enforced to be adopted for new systems - which is also the reason why even new subsystems added recently, don't support a proper reset/re-init.