Not disagreeing, in fact you are 100% right - but the thing is that consistency is a b*tch to get "right"
There are obvious areas like backward compatibility where consistency would help us a great deal.
But being consistent takes a great deal of work, not just in your own working areas, but especially in other areas that you have never touched.
Being consistent takes a lot of time, dedication, discipline and skill and a ton of networking. And it really isn't fun at all
We have an infinite number of examples for this being the case in FlightGear. It's not just our lack of standardized XML processing.
The whole MP/MMO debate is basically about the same thing - competing/conflicting features that never got updated and integrated, so that they end up crippling each other.
And we end up having a dozen way to "skin a cat" semi-properly
Being consistent means that "coding" (or even 3D modeling or developing FDMs) is suddenly no longer "just" about your own work, but looking at all the other places and potential use-cases in FlightGear that may benefit from it, including stuff that you never used, and never intend to use yourself.
To see for yourself, just ask yourself if any of your recent work (textures, 3D models, livery packs, FDMs, FDM components, autopilots, scripts, instruments or aircraft) can be easily used outside the context/scope that you designed them for originally ?
For instance, how easily can your aircraft:
- support being used by the AI traffic system ?
- support different liveries, liveries over MP ?
- dual-pilot use across multiplayer ?
- the weight& balance dialog ?
- the replay/flight recorder subsystem ?
- checklists ?
- autopilot dialog ?
- the bombable addon ?
...
These are all features in existence today that could be supported by aircraft developers - but most contributors only really scratch their own itch understandably
And that's really just the non-coding side of things - for programmers, pulling off consistent designs is often even more difficult.
As a coder, you permanently need to re-evaluate your own design and look at other/similar features, and see how those affect each other potentially - and be willing to modernize and re-implement certain stuff.
There's stuff like our networking stack, and the I/O system, along with its generic protocol system - and a httpd/telnet system, and of course the multiplayer system. All of this came into existence at different times - so are hardly integrated, even though they're sharing almost identical requirements, and could be re-implemented on top of 3-5 building blocks probably.
The Canvas/MapStructure work is another example for this: for over a decade, we've had various hard-coded instruments, a hard-coded GUI library, and certain 2D rendering code that could only be used within a fixed context, like 1) cockpit, 2) GUI, 3) scenery. It's only recently -thanks to canvas- that this is being unified and re-implemented, to hopefully get rid of a plethora of legacy features and modernize them through canvas and scripting space wrappers.
Previously, people could not render an instrument/HUD in a dialog, or vice versa - yet, this is a key feature, because supporting recursion means that even features like interactive map editors can share the same back-end code.
Today,
just the MapStructure framework is under 1k lines of code, and is making roughly 9k-15k lines of C++ code obsolete in FlightGear (agradar,groundradar,wxradar,map dialog), unifying the whole shebang in the process, which also ensures that more modern OSG/OpenGL can be used, i.e. better performance in the long-term.
This all has taken place in under 24 months actually (MapStructure just being 6 months old now actually) - whereas hard-coded instruments (wxradar, agradar, navdisplay,kln89 etc) are usually 5+ years old, and things like the Map dialog even older - in comparison, these were all "easier" to come up with in the first place, but obviously don't scale as well as a Canvas-based solution. Gijs NavDisplay framework is already better accessible and more feature-rich than the original ND code.
But this kind of work isn't exactly fun, it comprises lots of refactoring and is more about talking and coordinating things than actually coding stuff - because the implementation may very well just be a fraction the size of all the manifestations that are hopefully replaced over time.
To a similar degree, this is also what all the work on HLA is all about: increasing consistency (concurrency, distribution & multiplayer) , but it's taking time, as can be seen
So far, Canvas/MapStructure have helped make 2D maps available for
all needs in FlightGear, and a canvas/Nasal-based parser that processes our existing GUI dialogs/HUDs or 2D panels code would have the same benefits (GUI: 10k, HUD:3k, 2D panels:4k). Generic canvas/Nasal framework for each of those would probably also be under 4k in total. But it is so much easier being NOT consistent.