Is there any minimum speed value that needs to be scaled too?
There is indeed- Space.DeactivationManager.VelocityLowerLimit. I'll add that to the ApplyScale method.
With such an extreme scaling, you'll probably want to also look into some of the more esoteric values: Toolbox.BigEpsilon, Toolbox.Epsilon, MPRToolbox.SurfaceEpsilon, MPRToolbox.DepthRefinementEpsilon, MPRToolbox.RayCastSurfaceEpsilon, and SolverSettings.DefaultMinimumImpulse.
On the other hand, working on a more regular scale may be easier in general. Floating point numbers have a set amount of precision (
23 + 1 bits in singles, 52 + 1 in doubles). Compressing the entire planet into 2x2x2 cube does not actually improve numerical behavior because there's still only that fixed amount of precision.
From a simulation standpoint, you just need to guarantee that you have numerical resolution of around 1/1000 the size of an average-sized object or better (smaller). So, if an average object is around 2e-7 units across, you'll want a resolution around 2e-10 units. To span the entire globe with that detail, you'll need numbers spanning from -1 to 1 with resolution no less than 2e-10. If an object is all the way out at 1 whole unit from the origin, values must be of magnitude ~1 with discrete values available at least every 2e-10 units.
That is around 33 or 34 bits of precision required already, even though numbers are only spanning from -1 to 1. The important thing to note here is that simply rescaling the simulation does not change the bits of precision required. The radix 'floats' as the exponent changes. So, you don't lose anything by sticking to a more regular scale of ~1 unit for the average object and ~6 million units for the planet's radius. If you have enough bits of precision for one, you have enough for the other.
[Of course, to get those 33 or 34 bits of precision, you'll need to use doubles, but if I recall correctly you already are.]