Thank you, that's looking pretty good. Let's see what the devs are going to say
BTW: If you are interested in a more generic long-term solution, you might want to review the so called "instant replay/flight recorder" subsystem - which has a way to use an XML configuration way to specify if/how and when certain properties are to be recorded/replayed, it would seem pretty straightforward to use the same mechanism/idea to also synchronize/replicate relevant properties across multiple inter-linked fgfs instances, i.e. not specific to any particular use-case, just a generic property replication mechanism.
I guess, you will immediately see the potential behind this by briefly looking at README.flightrecorder in $FG_ROOT/Docs
The other feature you might be interested in is the so called "Emesary" messaging system:
The flight recorder/instant replay system has recently received some major updates by Julian Smith, and Emesary is maintained by Richard Harrison (both are active core developers).
Again, this will only be relevant if you are interested in working on a more generic scheme to sync arbitrary property lists across multiple fgfs instances, without it being specific to any particular use-case - the main benefit would be that such a scheme could be easily made to work for arbitrary aircraft, without requiring hard-coded changes, i.e. the setup would work via conventional PropertyList XML files.
Speaking in general, it would make sense to discuss the merits of this with the key people involved in the corresponding subsystems - for instance, Richard has not only come up with Emesary, but also has made major contributions to the multiplayer system, which is obviously networking related, and which is already using XDR encoding internally.
In other words, don't start any work related to this, if you haven't talked to the potential reviewers (devel list/issue tracker)
All of this is just to say, the original master/slave feature is a legacy feature, and many of the remaining core devs are unlikely to be aware of it, let alone be familiar with - and that applies particularly to aircraft developers, whose aircraft will rarely support the feature (which is also named somewhat unfortunately ...) Which is why it might be a good idea to revisit the underlying idea, and look at what else we have already, and see how this could be generalized/reused to accomplish the same thing, without hard-coding property lists.
The instant replay/flight recorder system is actively maintained, and also used by aircraft developers, so that a corresponding list of relevant properties can be easily determined at runtime, provided the aircraft has a corresponding configuration (which is otherwise easy to create).
Again, best to make up your own mind and discuss this with others interested in this aspect of FlightGear.
http://wiki.flightgear.org/Instant_Replayhttp://wiki.flightgear.org/Emesary