The astronomy sensor does not output your real coordinates. When you are below an altitude of 128km, it is your real coordinates, but above that only the z (north/south) axis remains "real".
above 128km, the astronomy sensor x coordinate is your radial deviation from a semicircle centred on (100000, 128000) with radius 100000 - at the start of the semicircle increasing your astronomy x makes you go east, near the middle it makes you go down, and near the end it makes you go west. The astronomy sensor y coordinate measures your projected arclength along the semicircle - it is equal to the angle subtended in radians multiplied by 100000, added on to the 128000m already travelled before the semicircle. Thus, if you are close to the centre of the semicircle, moving a small amount will change your astronomy y coordinate massively.

at the end of the semicircle, when you again go below 128km, you are now 48km above the moon. the direction of the x axis is still reversed (increasing astronomy x makes you go west), and the y axis is now also reversed (increasing astronomy y makes you go down). the y axis increases as you would then expect it to from what you have already travelled (astronomy y = 100000pi + 128000) up to the moons surface 48km below (astronomy y = 100000pi + 176000).

https://steamproxy-script.pipiskins.com/sharedfiles/filedetails/?id=3471401167 and
https://steamproxy-script.pipiskins.com/sharedfiles/filedetails/?id=3479131320
are microcontrollers I have made to convert between the two systems (make sure to read the description and output tooltips to not mix up the order of your y's and z's), or you can make your own.

Gravity and centrifugal acceleration are calculated using your real altitude, not your astronomy sensor y coordinate, and act in the real y axis, not the astronomy sensor y axis.
Gravity follows a realistic formula of:
a = -(gR^2)/((r+R)^2)
with
a equal to vertical acceleration,
g equal to 10 (or whatever your gravity game constant is modded to),
R equal to 300000/(sqrt(10)-1) (or approximately 138743), and
r equal to your altitude.

Centrifugal force follows a wildly unrealistic formula of:
a = clamp(r/40000,0,1) + (v/100)
with
a equal to vertical acceleration,
v equal to your horizontal speed, and
r equal to your altitude.

note that if you only care about your acceleration when outside of the atmosphere, the clamp statement can be reduced to simply 1.

so in total,
a = clamp(r/40000,0,1) + (v/100) - (gR^2)/((r+R)^2)

Given the aforementioned calculations for gravity and centrifugal force,

Orbits are possible but always unstable. Geostationary, the altitude at which orbit can be maintained by staying still, is at 300km. lower than that your required orbital velocity can be calculated from your altitude by rearanging the formula for vertical acceleration. It is impossible to have an orbit above 300km, for reasons outlined below.
If you are travelling too fast for the altitude you are at, or equivalently you are too high for the speed you are at, you will rise indefinitely. conversely, if you are too slow or low, you will fall until you hit either the earth or moon, depending on which you're above. Simulations done by reddit user Thattiguy show that at geostationary, having an altitude incorrect by 100m makes you drift about 8m in 3 minutes, while having a velocity incorrect by just 1m/s makes you drift 200m in the same time. As such, in order to remain in orbit, satellites and space stations need to be equipped with an RCS stabilisation system and, if planned for long operation, a way to refuel their RCS supplies.

The best altitude for minimising RCS usage is 300km, at geostationary, as this minimises the drift due to an incorrect altitude.

an orbit of 69111m travelling at 345.6m/s is the cheapest orbit to get to fuel-wise. any lower and you waste fuel gaining horizontal speed, any higher and you waste fuel gaining altitude. It is suboptimal for RCS usage in the long run, as drift due to altitude variation is relatively large.


(graphs supplied by reddit user Thattiguy)

If the game had introduced a coriolis force to slow you down horizontally as you rose or fell, elliptical orbits would be possible (and almost all orbits would be stable), but alas the devs did not.

the thrust force generated by a rocket engine is directly proportional to the incoming fuel flow rate (defining fuel as hydrogen + oxygen, in standard litres). The constant of this proportionality is the same for all three sizes of rockets available and is approximately equal to 110.22, henceforth refered to as "k". This is not a precise value (error about +/-1) and if I eventually narrow it down I will update this section. So the formula for rocket thrust is k*fuelflow.
Rockets use exactly twice as much hydrogen as oxygen.

Gasses in custom tanks are massless. This makes the Δv of a given craft equal to k*TotalFuel/TotalMass.
Gasses in preset tanks have a small amount of mass, so while not given here expect the Δv formula in that scenario to include logarithms.

various rearangements of the acceleration formulas show that the Δv required to get from the edge of space to a geostationary orbit is 870m/s. The Δv required to get to the moon from the edge of space is ~1010m/s. However, being fuel efficient drastically increases the amount of time it takes to get places - an optimal trip to the moon takes about an hour from the edge of space.

For my test craft, the Δv required to ascend from sea level to the edge of space is ~18450m/s. Note that if your craft is more aerodynamic than my cylinder of a test craft that number will be lower, but expect it to be similar. This figure assumes that you're doing a good job of not wasting fuel travelling faster than 500m/s.

Because the Δv requirement for getting to space is so much higher than what's used beyond that, a fuel efficient rocket will have a much larger first stage than upper stage, although both will be smaller than real life rockets stages. However, most people don't want to spend an hour travelling through empty space, so to get places faster at the cost of fuel efficiency, rockets may be designed with more standard proportions (although still likely smaller than real scale).