Certainly ring sigs don't automatically cause massive numbers of otherwise-unrelated transactions to suddenly depend on a rejected fork, especially if the fork is of limited duration. Granted there are slightly more dependencies, but that is quantitative difference not a qualitative one.
I posited to NewLiberty upthread that the development of a Gordian knot would depend on the duration of such an attack.
I argue it it also qualitative because my outputs get mixed in rings without my permission. Thus I can't spend in times of such an attack without incurring the risk that my spend must be unwound. Whether I know an attack is underway is irrelevant.
The Gordian knot problem remains interesting to me because it suggests an avenue of protocol improvement making CN more robust.
It presents a special case of managing a transaction where some ring signer (such as may result from a coinbase spend) is not valid due it being on a fork-to-be-orphaned, but the transaction ought be valid.
There is already some buttressing for this (in that fresh block rewards are unspendable for a good number of blocks). Which in practicality, amounts to a race between miners fixing checkpoints, and block rewards becoming spendable (this is the case for all coins not just CN, XMR however has a leg up in these races because no recompile is needed for the checkpoints).