Yes, to be fair though, I believe that there are a handful of aircraft using very custom Canvas displays, including code written by Omega95 and artix, who came up with custom Airbus displays and even a VSD if I remember correctly. I think rleibner also implemented the equivalent of a VSD inside one of his ATC related addons.
So depending on the functionality that the FG1000 has to offer, some of this may turn out rather useful and should probably be revisited.
Don't get me wrong, I truly believe that the FG1000 has come a long way already, but I think it is particularly important to also keep the offline use-case in mind (like Thorsten repeatedly mentioned on the devel list and the forum), i.e. offline is equivalent to people behind a low-bandwidth connection, and here relying on TerraSync, package managers, catalog systems and online chart services/web APIs is rather problematic, and it will cripple such fgfs versions for people downloading them years from now, because there are too many hard-coded assumptions about external services that may no longer be available.
Thus, I believe it is important to keep track of what people are coming up with and see if/how this can be added upstream, so that we provide a fallback mechanism for people whose fgfs box may not be behind a broadband connection.
Besides, from an encapsulation standpoint it's a good idea for such displays to use a single back-end/mechanism, even if that should be slow, because it can be easily updated in a holistic fashion, so that all places (aircraft) using such displays/layers will benefit automatically (imagine groundnet parsing or taxiway processing being implemented in C++ - as a matter of fact, we do have such C++ code readily available in Dave Luff's TaxiDraw code).