To elaborate on this, for the time being Nasal is extensively used all over the place in FlightGear - and there are bindings for doing many things, so it would be difficult (and a ton of work) to provide a compelling Python alternative, even just to bring FGPythonSys up to par with Nasal.
However, Nasal has its shortcomings, too - especially the way it had to be integrated inside FlightGear at the time.
Thus, for FGPythonSys to "succeed", the point is providing a real incentive - so that people can use Python to do things for which they cannot use Nasal, but which they would normally have to patch/rebuild fgfs by using C++
In summary, the way Nasal is currently integrated inside FlightGear brings a number of restrictions with it, so if a FGPython environment were to address those, it could quickly become a pretty relevant option among people wanting to contribute to FlightGear, namely:
- Nasal is currently restricted to a single global environment, i.e. there is no sandboxing for scripts running in different context (think aircraft scripts vs. scenery scripts vs. core/ui scripts)
- Nasal cannot be used to extend the built-in telnet daemon to register new scripted telnet commands
- Nasal cannot currently be used to register new canvas elements
- it is not straightforward to run Nasal scripts outside the main loop
- custom I/O protocols that require logic/heuristics (i.e. beyond what the generic protocol supports) cannot be implemented in Nasal, so that people use C++ instead
- Nasal cannot be used for PagedLOD/scenery stuff, so that it would make sense to provide FGPython with such bindings
- the Phi/mongoose back-end supports CGIs, but requires C++ to add such functionality, there is no support to run Nasal based CGIs to extend Phi server-side
- addons are exclusively Nasal for the time being, but would provide an excellent opportunity to use Python inside FlightGear in future addons
- An Emesary bridge would mean that PythonSys could access Nasal and vice versa
One of the lowest hanging fruits would be providing the equivalent of the addcommand() API so that Python functions can be registered as fgcommands.
So while Nasal is indeed almost everywhere, there are a number of places where it cannot be currently used, so that providing Python support there could be a huge technology enabler, even without having to port much/any of the existing functionality.
So there is no need to repeat all the mistakes that were made when Nasal got integrated, it makes much more sense to explore what it'd take to conquer those areas for which Nasal isn't currently available.
Being able to run parts of osm2city inside FlightGear via the addon API in a background thread would surely be a huge killer application for Python, and could very well spell the end of Nasal, if done properly ...