I love Orbiter (2006, 2010, 2016... I love them all), but they both suck at running 
with Wine, and don't run natively in anything other than Windows. This is 
especially sad, because it seems to me that many of the people that would enjoy
Linux, and those that would enjoy Orbiter are the same people.

Anyway, I don't know if I could ever write the "next Orbiter", but I'm going to
take a stab at writing my own take on space simulation.

I'm also sick and tired of "space simulators" that simulate space itself, but 
not much more, or that gives you 'Newtonian' motion, but with no gravity! 
Probably THE WORST give you non-inertial movement, no gravity, no physics.

Elite/OOlite is still pretty cool, though...

I'd like to implement multiplayer capability as well. I mean, who DOESN'T want 
a persistant, realistic MMO space sim?

Furthermore, in honor of Robert A. Heinlein, I'd like to provide some sort of 
interface for such things as sextants, astrolabes, slide-rules plotting tables,
etc. That way you can have your own classic sci-fi style adventures in the 
style of The Rolling Stones, Rocketship Galileo, or maybe even Starman Jones. 
Most likely, this will be in the form of an interface with pyNomo or some such.

At the moment, wasd -> camera controls(absolute), 
arrow keys , . -> rotate spaceship, 
spacebar -> print current altitude, velocity (I know, I know), and coordinates 
to terminal. 

I am trying to get the basic features all working, and then I'm going to clean 
up and modularize the code, and build an API. Using Guile as the extension 
language, but may use Python for GUI. For 3D models, I still need to decide on 
a file format, though it may be entirely procedural. That I can read into the 
program easily, but without a bunch of overhead (like .blend). must play nicely
with Blender.

A spacecraft (or pretty much anything else to be simulated) should be fully 
described by a Guile script. The API will provide procedures and such to make
such things as rocket motors, propellant tanks, aerodynamic surfaces, control
jets, docking ports, reactors, radiators, pipes and wires, gyros and precession
wheels, etc. Generating a component creates a mesh for it, as well as physical
properties like mass, fluid capacity, drag coefficient, etc. It will also
create all the necessary hooks for simulation, and procedures for control 
input, and instrument output (e.g.: engine temperature reading, cabin pressure,
gyro angles, etc for instrument output. Throttle setting, RCS impulses, docking
port manipulation, engine gimbal angle, structural decoupling, etc. for control
inputs). 
Once all these functions are exposed, they can all be tied into each other,
and hooked into the interface through API hooks and callbacks. The API will
provide hooks and callbacks to create instrument and control panels. 
This way, it is easy enough for anyone to create spacecraft and such without
requiring any special tools or skills with 3D editors and such. It also ensures
that all user-created spacecraft and such follow standards, and are therefore
realistic, and compatible with the simulator, and all other spacecraft. This 
way, in a multi-user environment, all vessels are sane, and all players have to
obey the same laws of physics.

For those of me who are curious like me, I will probably implement the EMDrive
and/or the Cannae drive (though, I'm less sure about that one) so we can see 
it MIGHT work in practice, and maybe try out some conceptual designs.

UPDATE:
Since Children of a Dead Earth came out, and since it is basically everything I 
want in a space game, and furthermore because the author seems to be ignoring the 
Linux community (which, again, is missing out on a STUNNING opportunity to tap 
into an engaged and energetic user base), I have decided to take some time, and
reevaluate which direction this project should go in, if any. Some questions are:
Is there any way that I could do it better?
Is there more demand for a simulation like Orbiter, or for a game like CoaDE?
Should I perhaps switch to an already well-developed game engine to handle the 
input and display and such? If so, would the bundled physics engine be sufficient,
or would I need to write my own? Similarly, are the display capabilities sufficient
(extremely long view distances, long LOD chains, realistic lighting without pre-baking...)?