In general, we still lack the kind of sophistication needed to actually implement the differences in avionics/FMS between an airliner like the 747/777 and the Citation.
However, often, aircraft developers are primarily 3D modelers, so they primarily care about the 3D models of those instruments and buttons, so that they manage to actually create separate models for each instrument.
Then, the next problem is that people tend to use competing or even conflicting approaches that are not compatible with other aircraft, i.e. due to fixed assumptions about certain systems, or even just due to hard-coded properties. We've been recently seeing the same issue with other aircraft and glass avionics, even those that were designed from the beginning to use Canvas - people still tend to re-invent the wheel instead of teaming up with others - some even express the concern that collaboration would be "too expensive"", and they would have to neglect their main project due to sidekicks - that's something that the extra500 recently told us when we got in touch with them, encouraging to team up with us to generalize their work and reduce their workload.
So far, we simply don't have any kind of "standard" interface for a FMS, or even just M/CDU, except for the route manager/autopilot interface via the property tree obviously.
But otherwise, people tend to make up their own stuff, with very little concern for standardization. Obviously, because it's more work to coordinate things among several aircraft developers, and because understanding an existing system, integrating & adapting it, takes more energy for most people than understanding their own system/code, no matter how limited it may be - simply because they wrote it from scratch.
For a hardware interfacing project, I'd recommend to come up with your own standard interface, and document it via the wiki, so that aircraft developers need to adopt it in order to support your hardware.
That should be the safest thing to do from your standpoint - simply because most aircraft developers don't have the technical/programming background to actually come up with an aircraft agnostic system/interface that would actually work for different aircraft, and possibly also multiple instances (MCP/CDU) per aircraft.
So, I'd suggest not to look at existing stuff in FG, unless it looks really compelling from an interfacing standpoint (which I'd find surprising, but still great ...)
Overall, consistency/standardization really isn't our greatest forte, which comes with the territory of being "open", but also extremely flexible: properties and Nasal functions or fgcommand don't care about naming conventions, backward compatibility etc.