I'm not sure I understand the need for hard forks. We can get through this crisis by mining pool collusion to prevent forking blocks until there is widespread adoption of patched clients.
Proposal:
1) Patch the pre-0.8 branches to support an increased lock count, whatever number is required to make sure that this problem never shows up again at the current block size (I defer to Luke-Jr and gmaxwell's numbers on this).
2) Patch all branches to not *generate* blocks which trigger the lock count limit. A larger block would still be accepted as valid, however, if it is on the longest chain.
3) Simultaneously, provide an additional non-standard patch to mining pool operators (>>50% network hash) *rejecting* blocks that trigger the lock count limit. This keeps miners in collusion with each other to stay on a 'compatibility fork'.
4) At some point in the future once we've crossed an acceptable adoption threshold, the miners remove the above patch in a coordinated way.
Does that not get us past this crisis without a hard-fork?
(Aside: I'm for BOTH raising the block-size limit and off-chain transactions, but like it or not there are political sides to that debate and we should keep politics out of crisis management.)