Decoded stack trace:

numerics/fit_hermite_spline_body.hpp:85
physics/discrete_trajectory_body.hpp:179
ksp_plugin/vessel.cpp:431
ksp_plugin/vessel.cpp:191
ksp_plugin/plugin.cpp:756
base/thread_pool_body.hpp:80

So the check tells us that downsampling was not effective, which is indeed similar to #1628.

I think I have a theory.

We detect collisions in the force computations and bubble up a status to the integrator. The integrator squirrels away that status and keeps integrating no matter what. Once the desired time has been reached it returns the status. This is important to preserve the invariant that desired time has been reached. Anyway, so far so good because the trajectory of the pile-up is not downsampled.

Then we advance the time of the vessel. To do this we take the trajectory of the pile-up, which is probably quite chaotic, and use it to construct the trajectory of the vessel, which is downsampled. Things go downhill from there.

I am tempted to say: don't build a trajectory for a vessel that you are going to destroy anyway, but I am concerned that not calling Vessel::AdvanceTime in this case might break invariants...