If you were to impliment something like an "astronaut" class it would need to be very abstract. Most of the functionality is already contained in the VESSEL class, except for the EVAing, and transferring.
Very abstract for sure. My idea would be to unpack some functionality from the vessel class into some kind of "DynamicObject" class or somesuch, from which vehicles, vessels and astronauts would derive, so you can reuse the code they all share.
EDIT: Alternatively, I guess the whole VESSEL could be restructured as an ECS, so different behaviour can be switched out by composition... But that would pretty much break
all backward compatibility. That would be more like a VesselV2 interface...
I think attachments might be a good basis for this. An 'astronaut' is basically a vessel that becomes invisible when attached and magically frees up the attachment port....
I strongly disagree with such hacks. Anything that happens
inside a vessel should stay inside that vessel. Leave it to vessel implementations what they do with astronauts on board. That is
exactly the kind of thing I would keep out of the core like the pest. What the core would need to provide is a common interface for vessels to accept or spawn astronauts, and
perhaps some minimally functional base class for the astronaut when it's
outside any vehicle.
As soon as it's inside anywhere, it should really seize to exist for the core, or at least be removed from any calculations.