I'm also looking forward to Greg's post-mortem, because I had a completely different takeaway from the BIP66 mini-forks.  My view is that despite the extremely cautious and conservative planning for the completely uncontentious fork, the damage could and would have been very significant if it had not been for several core devs manually monitoring, intervening and problem solving for other network participants.  I don't believe thats the way the system should work.  Participants in the Bitcoin community have come to rely on the devs for just making sure everything works for them.  That's not sustainable.  The system needs to be made fundamentally more secure if its going to succeed, not depend on the good will of any particular parties, otherwise it certainly will no longer be permissionless.

The BIP66 fork was urgently required to fix an undisclosed consensus bug, unanimously agreed on and without technical objection, and it was still fraught with problems.  That's the most clear cut example of when we should have a fork.  A change to a consensus limit that a significant proportion of the community disagrees with for economic or technical reasons or both should be raising a sea of red flags.