Since those mothballed transactions are not publicly accessible, there is no way for soft-fork proponents to make sure that they will not be invalidated.
Barring emergency fixes, you can make it so that the change depends on the transaction version number. Any soft fork should be backwards compatible, unless there is a good reason not to.
In some cases (such as security or bug fixes), they must be invalidated.
Even for security and bug fixes, the objective should be to not make any transactions invalid. If that isn't possible, then keep the number to a minimum.
Transaction which use an undefined version number are fair game though.
This may be bad news for the Lightning Network. The latest attempt at the LN design, IIUC, uses long-lived bidirectional channels, and unconfirmed and unbroadcast transactions ("cheques") that may have to be held by the participants for months or years.
A soft fork which breaks the Lightning Network would have significant opposition. You are likely much safer if you use transactions of a type that are very popular. Breaking unusual edge cases is one thing, breaking extremely popular transaction formats is another.