There is no real Moon in FG, and I suppose to include it with celestial dynamcs, detailed enough landing sites, and illumination accounting, is too big work which would take long years. It's surely not task of Nasal level. You could not make it as addon, You need to get down to the core.
I don't think it's a good idea to start this discussion again, like all of us know meanwhile (you and myself included), it has caused lots of frustration within the community.
As you can see, there's lots of stuff possible just from Nasal, without even touching the C++ code. Nasal is very good for prototyping purposes, like Thorsten has demonstrated once again.
And once you actually touch the C++ code (i.e. see Ron's atmosphere patch), things become even more convincing.
So I still wouldn't completely disregard Nasal here, it's always very easy to say "not possible in Nasal" and "requires C++ work" and "we need three guys" - but that's not necessarily true most of the time.
You could accomplish a LOT just by by disabling certain core features or making them slightly more configurable using a handful of properties. Exposing a control interface (via Nasal or the property tree) would be another option. Obviously, you are -once again- striving for a perfect solution - but that won't be available if you are not willing to compromise in the meantime.
Yes, obviously FlightGear doesn't currently have elevation data for celestial bodies like the moon or mars - on the other hand, once you get your hands on the data, you could could create coarse 3D models to dynamically add them to FG (using Nasal!). You might even be able to find a textured 3D model for moon or mars online.
Once you have 3D models for moon and mars you could -again- use Nasal to manage everything (i.e. placing models, transforming and animating the scene).
You could probably even use a slightly modified TerraGear toolchain to come up with native BTG terrain tiles, too. There are probably a number of hard coded assumptions, but apart from that it should be a matter of converting GIS data from several input formats to the FG output format and disabling tons of code (lakes, roads, airports, runways).
What I am trying to say is, you need to be able and willing to compromise, i.e. reuse what's there already and combine different things.
For example, doing a quick google search, brought up this free 3D model of the moon:
http://www.turbosquid.com/FullPreview/I ... /ID/553741Just searching for "moon 3d model download DEM" yields many other matches.
Thorsten's approach could certainly be generalized to add a bunch of other models and animate then properly.
So, if that's what you are interested in (i.e. flying to moon and mars), it would certainly be possible to come up with a workaround in Nasal space. Once you hit show stoppers, we can still look at switching off some core features or making them more configurable using a bunch of properties.
So it would be very good if in 2019 someone will step on Moon in FG space, but it would be miracle if someone could do it faster. And that is surely not one man task, that fact is historically proven.
I don't think the analogy is appropriate or even applicable: Just use a little imagination and ask yourself: what if Thorsten had used a textured 3D model of the Moon or Mars instead of Earth? And what if the tile loader were to be patched so that it could load tiles from a custom location on demand?
None of that is "rocket science" (pun intended) and it would only require very little C++ work on the C++ side.
I wouldn't even be surprised if you could come up with a workaround to trick the tile loader into loading custom scenery tiles ,without modifying the C++ code.