Actually, I wouldn't simply discount the idea - my response mentioned already the fact that the idea is not as far-fetched as it may seem to people not familiar with the code in question.
The point being not just that Torsten stated fgpanel would now be superseded by Phi (which in turn supports streaming Canvas textures these days), but that the 2D panel code does in fact use so called od_gauge instruments (=owner-drawn), which is also how the Canvas system started out, i.e. both systems were basically sub-classing/using the same class. Under the hood, it's using an OSG StaticTextureVisitor to traverse the scenegraph and replace the static texture with the dynamic one.
Thus, the only thing that really matters is having an identifier token for the visitor, and obviously using a scenegraph handle that contains the node to be replaced.
Without having looked at the code in question (and without having access to fgfs), I would definitely recommend playing with this - because ultimately it depends really only on the node that the visitor is traversing and the token that is used to look up the matching texture.
If you can make the Canvas system replace/attach to a static panel texture to show canvas contents, you can also make it show the FG1000. You may be in for a surprise here, under the hood the same mechanisms are in use, and the APIs involved are fairly basic, too.
Let's keep in mind that the 2D panel code only works in terms of static textures stacked on top of each other - the only exception being od_gauge based instruments (wxradar, agradar, groundradar, navdisplay), which are using static textures that are to be replaced with the dynamic ones later on.
In turn, the only relevant "output" that a Canvas creates is in fact also an OpenGL texture.
PS: You should be able to invoke addPlacement() using either combination of texture/node/parent to "filter" the graph. If you don't mind experimenting a bit, I'd suggest to dump the scenegraph (debug menu) and use a really simple location/aircraft to see what the scenegraph looks like. I wouldn't be that surprised if you can just make it work without having to patch FlightGear at all (again, without access to fgfs and without having looked at the code, purely based on the underlying texture visitor/replacement mechanism being de-facto the same). Personally, I'd expect event handling to be possibly problematic, because that is touching issues that we ran into when we began supporting Canvas widgets rendered via PUI (which is kinda using the same basic OpenGL functionality that the 2D panels code is using).