The game is P2P, the session are hosted by the peers themselves. If one of them quits, their session is de facto terminated and there is nobody you can trust with hosting it in their stead to keep them in the game. Most respectable MMOs go around this by hosting virtually everything on a master (well, a farm of) server which they 100% trust, but FD decided to cut corner and trust everybody with their own little bubble in which they can do whatever they please with the exception of a few things covered by the transactions server. That's the price you pay for a one-time purchase without monthly fees. You can't make a competitive open world game on that model because people will simply exploit the hell out of it and you can do nothing but put stop gap solution in place with no real fix, because the issue is a fundamental one. All the solutions FD will put in place will have flaws easily exploited, because they will either rely on the clients themselves sending telemetry data to spy on themselves and others, data which you can both stop from being sent or even fake to protect yourself or lie about other users, or be intrusive anti-cheat solutions like Punkbuster, which can only protect against old known cheats and take away the users right to have total control over his computer and have been known to spy on users regarding things not related to the game.
FD certainly shot themselves in the foot going for a P2P design instead of the tried and tested solution of a server farm; if it's good enough for the biggest MMO's in gaming history, it should certainly have been good enough for FD.
But, to clarify, I know the game is P2P but this doesn't automatically stop one from telling the clients how to behave. They still need to communicate with the server; even if they do act as their own mini-servers for instancing.
My comment implied ( or, I thought it did,

) that some control would have to be moved over to the server. The server doesn't need to control everything, only the session states. The client talks to the server regularly anyway, therefore the client could send through a "I'm still alive" flag with every (or every other) packet (if it doesn't already). If the server doesn't receive that notification from the client, then the server flags that connection in an "idle" state; during this state the server notifies the other clients in the instance; which in turn forces the clients still connected to simply show a ship floating in space, perhaps with a "disconnected" icon above it. AI stop targeting it; but players can still attack if they want.
During this idle state, the server logs the state of the ship (health etc). If the ship is destroyed, then the next time the client logs in, the server sends that packet through with the updated ship information which the client then knows what to do with. I can imagine the cries of frustration when the combat logging chickens log back in with a smug look on their face only to find a "Your ship was destroyed" message waiting for them.
Granted this won't completely remove the problem and neither is it fool-proof, but it will at the least (I hope) make the concept of combat logging less inviting.