How would "Astronauts" be updated (pre and post step) when they are "in" a vessel?
I really hope they wouldn't be. In my opinion, when an astronaut enters a vessel, the job of the core is done. What would you want to update anyways? You can't put things like eating or breathing into the core, because that would mean you'd have to provide interfaces for vessels to provide consumables to an astronaut like propellant to a thruster, and things for the vessel developer can quickly get very, very tedious.
My suggestion would be to invoke a callback on the vessel that hands off a data structure that can be used to instantiate the astronaut again outside, and have the callback return true or false. If true, the core assumes the vessel has accommodated the astronaut and destroys the simulation representation, if false it assumes that it was prevented from entering for whatever reason and leaves it as is.
What exactly happens with the astronaut inside the vessel is the vessels concern. A library could be written for that too, of course, but there's no reason for that to go into the core.
Just an idea : it would be nice to have a simple timer when you transfer crews, in uMMu you could teleport crew members all across a Star Destroyer, it worked but wasn't super-immersive.
Again, not a concern of the core, in my opinion. There's nothing preventing a vessel from implementing an internal layout and have its astronauts wuzzing about inside it Sims style (except it's an awful amount of work). If you start implementing such basic mechanics in the core, you
loose that flexibility on the vessel side. Again, a generic crew library that implements layout patterns and behaviours can be written and can be pulled in by each vessel as they see fit, no need to dictate it from the core.
I think the thing many people here are unclear about is: The core is THE LAW! Whatever behaviour the core defines, requires hacks and workarounds when you want to change that behaviour. Again I will mention thrusters and propellant sources: Everybody that wants to implement fuel mixtures basically has to hack that pattern by substituting a dummy propellant source and then feeding that from their own structures somehow. In other words, the core provides convenient functionality that can save you a lot of work if you're just doing what the core intended, but it it also
limits your freedom if you need things differently.
Therefore, behaviour that can be generalised and abstracted away from the core, should be done there. That way, you retain convenience
and flexibility, because everybody can decide for themselves whether they want that functionality implemented this way or not. If it's in the core, you're just stuck with it.