The software currently allows up to a two hour difference between the system clock and the time implied by a fresh block's timestamp (if I remember correctly). This reliance on realtime system clocks can be used in a much weaker form to justify a plan for a difficulty adjustment to be built into the software for when the expected block production rate is far enough behind its expected value.
We would have to agree on how far behind mining should be to justify expediting the adjustment. The sooner we decide on and implement this second difficulty adjustment trigger, the better. It cuts off a nightmare scenario made possible by collusion between states through regulation and fiat, as well as any other external factors. I propose that miners detecting that the expected 2016 blocks have not been mined after twice the expected wait time (4032 * 10 minutes = 28 days) ought to signal their recognition in any block they produce, to be rejected by any miner whose clock disagrees (after taking into account the 2-hour leeway), and that any block produced on top of one with such a signal should reflect an expedited difficulty adjustment (and also include the signal), which is then in effect for the rest of the 2016 blocks and the entire following difficulty period. Every block from there until the modulo 2016 block should have the same signal, which not only indicates that a difficulty adjustment was expedited, but also that the next modulo 2016 block should not make one, but rather turn off the signal.
If anyone thinks it's a good enough idea for a BIP, I will consider writing one unless someone else wants to.
Dave.