everything you said is entirely correct - feel free to get in touch if you need any clarification/explanations regarding the docs/code that you can find.
It would be greatly appreciated if you could document your journey - I won't mind to review the corresponding code and extend the docs where needed.
My only request would be to help us review/extend the wiki docs accordingly, so that others can more easily do what you are doing.
In general, it would also be a good idea to get in touch with artix who has the most recent experience modifying the ND "framework" in a major way.
Apart from that, you will want to make sure that you understand Nasal basics, especially hashes.
Apart from that, the "framework" is sufficiently basic that you won't need to understand much/any OOP - it basically works by traversing a vector of hashes that contain callbacks that invoke each other, i.e. the first callback checks some configurable condition, and then there are true/false callbacks that will be invoked depending on the conditional check.
So it really is rather basic (but very convoluted) - you can definitely review the Boeing/Airbus code to learn how everything works, and even copy the existing code and modify it according to your requirements.
There are some "todo" items on our list (see the wiki), but for those you will want to really understand the .mfd file itself, which provides the underlying framework to make the *.styles stuff work - which really is all you (should) need to understand to add/customize other styles.
Note that in general, your final question seems to suggest that shipping such aircraft specifics would be a good idea - and it does sound good in theory, but in practice, the "framework" part of said code hasn't much evolved since its early days (which is heavily based on Gijs' original implementation that would only support a single aircraft/instrument, style and instance) - so that it really does make sense to add to a single *.styles file, and extend/modify the .mfd file according to any requirements, so that all aircraft, and aircraft developers, can benefit from the way this will unfold, regardless of their aircraft/priorities.
I think artix managed to break/work around this idea by using some very fancy/clever, and unprecedented, Nasal hacks - so if in doubt, get in touch with him or even just review his code.
Speaking in general, we were hoping for the ND stuff to become sufficiently generic so that it would primarily work in terms of what you see in the .styles file, and to let the .mfd file become sufficiently generic to also let other displays like the PFD be supported. Since then, many things have changed and happened - so that it would actually make sense to clean up the mfd file to use Richard's MFD framework, and prepare it for using Richard's Emesary framework, too.
As usual, spare time is our primary constraint - so, obviously anybody interested in using/extending the system is invited to get involved - if in doubt, feel free to get in touch with fgdata committers who can help you get your changes committed - I think Hyde, Richard and others have used the system more recently (see the wiki for details).
Finally, if you are familiar with OOP, the ND code will look fairly alien to you - but the whole .styles approach is there for a reason, it would at soem point be possible to make the whole thing totally declarative (think PropertyList XML), and to encapsulate concepts like animation handling, so that there is a single Nasal API implementing the details, which will also make it much easier to update all instruments/code using such APIs, which means that core changes will propagate much better, and more easily, than not using a purely declarative approach - which is the primary reason why we ended up using a bunch of embedded hashes, so that the whole thing could evolve beyond supporting just a single instrument, aircraft, instance or ND - i.e. for arbitrary MFDs, including Gijs' original PFD work.
The other use-case this approach can easily support is MFDs shown in GUI dialogs, even without requiring an actual aircraft/cockpit - including even independent instruments linked to different "source aircraft" (think AI/MP traffic nodes) - all of this is to say that there are no hard-coded dependencies to the aircraft, i.e. the whole thing is configurable via a driver hash, and the motivation for that was supporting avionics for arbitrary purposes, imagine AWACS aircraft with an actual ATC station, or showing traffic conflicts from different perspectives, or even just integrating MFDs with the tutorial system.
All of this is not just prepared but actually working and very accessible to people not very familiar with coding - so even in the light of the current "design", it's a rather functional piece of a hack by most standards