Lots of questions, I did tackle a few of those topics with my implementation already, but some are still to be done, however in that case I am going to share my thoughts at least. Please note that some parts heavily depend on which basic design you choose and possibly different strategies make more sense in case you develop your own engine.
Yes. In fact I've been working on this topic in multiple iterations now, profiling different implementation strategies.
Currently I am in my third or fourth iteration of the scaling system. Currently I think I've found a good design approach I like and want to proceed with because of its structure and performance. Its based on a singleton-centric "SpaceManager". Space is my term for a specific scale state in the sense of the size of the object itself, positioning and movement (all three aspects have to be scaled!) combined with multiple "SpaceControllers" instanced for each object that possibly could change a scale state. The singleton SpaceManager is basically something where objects registers or deregisters for a specific space, where the resizing/repositioning-code is (I dont want to spread this stuff but keep it centric somewhere is good as possible), or where some unique data is being maintained (scale definitions for each space, etc.) which should be the same for all SpaceControllers. The SpaceControllers check regularly if their object which they are applied to has to do a scale change, and communicate with the SpaceManager.
In my case I also added the ReferenceFrameVelocity handling (to allow higher velocity than the physics engine can handle) to the SpaceController. I wasnt sure if I should add that to the same class, but since the velocity also depends on the scale I was fine with it in the end.
I also did spend some time to find the best datastructure (hasmap/-table or dictionaries vs. lists vs you-name-it.. ) for the performance, or check where to avoid data lookups completely and go for simple switch/case structures etc. Perfomance is crucial, as while you move through space, objects might have to change scales states quite quickly and often. For the SpaceManager I ended on hashtables for keeping references to objects that register for a space and for segments where I had to do different stuff depending on the space (e.g. apply a certain scale value) I sticked to simple switch/case code instead of more beautiful dictionary lookups because they were a lot slower than switch/case code (unless you reach a certain number of elements).
One thing I added in my last/current iteration is that the more an object is scaled down the less often over multiple frames I check if I need to change the scale or LOD of the object. A low scale means most likely the object is currently very far away and, since velocity also depends on scale, slower movement makes the need for regular updates less important. Think of driving in a car looking ahead. Close objects such as a tree move very quickly to you while the very far away objects such as a hill moves miles away moves very slowly ahead. I also apply ReferenceFrameVelocity less often to the farer objects and dont move them each frame, due to the same effect. Even though the hill moves at the same speed as the tree next to your car, you dont notice the hill movement unless it gets closer. So it makes sense to make use of that.
How to manage the various scales (which can differ enormously) and how to store the position of an object are two separate topics IMHO, you need different strategies (and do face different problems ) for both. Positioning of objects in my case is based on doubles. I store each object's position in stacked/multiple double precision values, or to be more precise, in multiple double-based Vector3 types per object.
I've not added too much physics to the implementation yet, besides for the spaceship. So the following is pure theory:
In terms of gravity based physics: My strategy is to either manipulate the global gravitional direction dynamically (easy in Unity) or, which is my prefered way to go, applying forces (which consider the gravity center e.g. of a planet) to each object individually to simulate the gravitational pulling effect. This is not too complicate to add and should be more precise than just working with the global Physics gravity-value. And as I made some effect to calculate the mass of each celestial body, I could consider these values too to calculate the necessary force.
This heaviliy depends on the overall implementation strategy you choose. If you simply think in a single worldspace this becomes a problem, yes. In my case that is not a problem because of the "floating origin" approach, where the camera is always at the worldspace origin, so there is always the highest precision for positioning and physics (around the camera) available.
Of course "floating origin" comes with a price, besides the implementation effort itself (and finding the most performant strategy) and a few "harder to do" 's (e.g. collision) you have to let go the idea that worldspace defines the position of an object. That is hard to overcome. I think this is something you have to get used to at universe scales anyway, but it becomes harder with floating origin. It helped me to always compare worldspace using floating origin like a small stage (a room, which is your worldspace based on float with a camera inside) that moves through a larger space around it. Objects stream in and out into the room as they intersect the room. In that case it becomes obvious that latest at that point you also need a higher level custom coordinate system for all objects (and for your current position). Because a) float or double is not sufficient anyway, and b) you cannot use your engines worldspace coordinate system within your room (because it is not static from a higher level perspective outside the room).
PS: Dont think of it that the "room" limits what is visible. The above describes only how to think of floating origin, of course this can be combined with different scales which allows a high viewrange.
I can try to add a few sketches for that if you want, however the situation might be totally different if you choose something different than floating origin.
Based on my previous prototypes with Unity you have at least the following very very basic problems to tackle separately:
* Worldspace precision at least if you go with a float based engine, you loose precision way to quickly.
* Scale (Object-Scale, Initial positioning, Movement) due to small vs. very large scale sizes and distance of objects)
* Positioning and Object-Coordinates due to insuffiency of float and double for anything above a solar system
* Velocity due to the large distances which require velocity that makes your physics engine go nuts
* Instance and destroy objects and when you do what to stay efficient streaming in and out objects.
* Instancing and access to objects in general because a few parts of what might look appealing in Unity might not be quick.