as I said already, "the best" solution depends entirely on the circumstances - I specifically mentioned latencies as the most likely issue here.
sync'ing (replicating) a Canvas MFD to another fgfs instance would also be possible, I actually once did that in the early Canvas days, at the property-level.
These days, it would be better to use Richard's MFD/Emesary framework for this - because that would mean that only relevant state changes would need to be propagated (selectively), rather than full 1:1: Canvas primitives at the property level.
To some extend, the ND code is prepared for this use-case, by using the notion of "driver hashes", which is to say that these are the equivalent of "data providers" (think properties, but also Nasal APIs, e.g. to query terrain elevation) - thus, at the mere cost of replacing the driver hash, all higher-level code would automatically use a different "data provider", which means that even other fgfs instances could feed the corresponding data in a master/slave fashion - with each slaved fgfs client still running a local copy of the instrument/display logics (avionics), just not sync'ing low-level state with the main/master instance, but only relevant state changes are propagated.
However, that makes really only sense to explore once you understand the concepts involved here, and how there are overlapping requirements between the MP/dual-control mechanism and the fgtape/instant replay (flight recorder) system, and how this relates to sync'ing/replicating certain state to another process (fgfs instance, or 3rd party Canvas implementation in the form of FGQCanvas).
There's really no way to tackle this properly without having a strong coding background, particularly in the Nasal/Canvas department and the fgfs/networking component (MP).
Thus, if you aren't eager to duplicate work unnecessarily, Richard's MFD/Emesary approach is the most promising option for the time being - but that requires a different coding approach, too.
Feel free to file a feature request - but like I said, we do already have various bits for this in place (in the form of several patches), it's just that the response so far has been rather trepid, so we didn't exactly go out of our way to integrate any of this with upstream fgfs.
Anyway, for the time being, the streaming option provides the most bang for the buck for people able to patch/rebuild from source, without requiring any coding experience.
If you want to do this properly, without any of this being specific to any particular instrument/aircraft or effort, there's no way around using an IPC mechanism and formalizing the synchronization/replication requirements, analogous to how MP/dual-control and the flight recorder subsystems are already doing that.
Which is to say, I would not expend even just a single second thinking about it, let alone working on it, if this sounds like some fancy gibberish, because then you're really just wasting your time, and will find it hugely frustrating should someone come up with a more proper solution (say, using Richard's MFD/Emesary integration).
Originally, we were wanting to make this master/slave use-case a first class concept of the whole Canvas system, but then RL took over, and other things were more important, technical background (includinig suggested approach at the sc::Element level) at:
http://wiki.flightgear.org/Canvas_Devel ... FlightGearPS: In a "perfect world", FlightGear would have a working HLA/RTI or CIGI implementation ...