I like FlightGear a lot, and have spent countless hours learning to fly various aircraft. I'm not involved in FlightGear development, so I might not be the best person to tell you this, but here goes:
Nasal must go!
Nasal is indeed a versatile scripting language and a great piece of work. At the time it was created, in 2003, it was arguably the best choice to go forward as a scripting language.
But times have changed. CPUs and GPUs have been getting faster. PCs have more than one core, Windows has become a serious operating system. Users have more than one device. Machine Learning has become a thing. "Scripting" languages like Javascript, Python and Lua have not only matured, and have gotten ridiculously faster, but they are now often used to run software in their own right, not just as extensions.
Today, Javascript, Python and Lua have surpassed Nasal in pretty much everything the FlightGear community cares about (in my opinion): performance (garbage collection, jit etc), concurrency, parallelism, bindings, language ecosystem, and especially the developer base.
I know FlightGear can't just ditch Nasal. Bringing another scripting language into the fold would certainly be a big undertaking. I have done some experimentation around using Python's asyncio with the websocket API (which is faster than the telnet btw), and if I were to write an extension I would probably use this approach. It means I can use the whole scientific python stuff (for example GIS, but also machine learning), and have all my processing in a separate process. It's conceivable to implement AI planes, virtual instructors, missions and much more with this. Even for aircraft systems I see some advantages. I've been perpetually frustrated with setting up my input devices for flight gear, and thinking about writing scripts to circumvent the clumsy configuration system in FG. Using different configurations for different aircraft is also a pain point, but that's another story.
The GUI in FlightGear is crap. This is also understandable, since FlightGear is a very old multi-platform Application. Nasal doesn't have bindings to things like GTK, nor was GTK on Windows an option back then. WebUI wasn't a thing back then. Yet another thing which could be better, if FlightGear adopted a modern scripting language into the core, or a better integration with external programs.
The 3D software package Blender, as a comparison, is an open source project even older than FlightGear, plagued by very similar problems. It's mainly written in C, but it is under much more active and agile development than FlightGear. Part of this, of course, is that there are more commercial resources involved. But another big part is that Blender chose Python as its extension language, and with Python improving over 20 years, the C code base and Python extensions are a killer combination.
As a user of FlightGear and as a Python developer with the occasional improvement idea I find myself frustrated by having to shave too many yaks. One of my wishes would be some kind of unifying platform: A modern launcher UI (maybe even as a webapp) which can launch FlightGear, configure certain stuff (during FG running) and arrange communications with third-party processes implemented in Python or other languages. These would then manage scenarios, AI, maybe even input devices and aircraft systems. Of course, this would need a better integration of remote protocols into FG. The user wouldn't notice anything of the hidden processes, because the launcher/manager takes care of everything, even the spawning and killing of the auxiliary processes.
Let me know what you think about it. Again, I don't want to bash on Nasal or the FlightGear project, I just wanted to vent some frustration and fantasize about a way out of it.