It is very encouraging to see a prominent figure like OP starts a topic about this event admitting that there are lessons to be learned and measures to be taken. kudos theymos.  

I understand there are many people with various incentives mostly not in the best interests of bitcoin who may find such an event a good opportunity to take advantage in an irresponsible and unproductive way. Although I have a reputation on this forum to be somewhat discontented with Core devs, I hope my statements here other than being helpful in the context of this topic, would show how committed I'm to bitcoin as a liberating movement instead of blindly opposing and fighting with specific parties.

Seemingly, the "multiple implementations proposal" is trending right now in this thread. I don't know to what extent it could be considered a healthy proposal with good intentions but I'm sure it is neither correct nor practical to be considered an effective measure against vulnerabilities to implementation bugs. On the contrary it seems to be more dangerous rather than a helpful strategy.

Being decentralized does not change the fact that bitcoin is an integrated meta-system. Running multiple implementations of code in such a system is not recommended because it adds another complexity factor: Multiple implementations means more lines of code and hence more bugs. It will cause frequent chain splits and encourages a new range of sybil attacks.

Suggesting that no implementation should be used by a majority, besides its impracticality (who is in charge of imposing this rule?) does not seem to be of much help with this idea:
Firstly, it implies a new kind of consensus system, with no theoretical support. I'm not aware of any serious work covering a decentralized consensus based system that uses heterogeneity of implementations as a main or auxiliary security measure e.g. for immunity against software bugs.

Secondly, it is very unlikely that such an evenly distributed heterogeneity might help in damage control by localizing bugs. Nodes have to validate blocks independently and they don't apply longest/heaviest chain rule unless they have validated both chains beforehand. It is impossible for a wallet to feel something is wrong with its own code and decide to follow the majority blindly. One possible solution for such a schema would be running multiple implementations by a single federated node that uses a BFT algorithm to make final decisions. It has been suggested up-thread somehow and is infeasible because of  exaggerated costs and complexities involved.

Thirdly, adversaries would find it feasible to identify flaws in a single implementation and targeting its users (which typically are a minority) without compromising the whole ecosystem explicitly. In this scenario, although bitcoin won't collapse dramatically but the scammers might consider it an advantage as the funds they steal, preserve their value.

Conclusively, I would say this proposal, encouraging development and hiring multiple implementations of bitcoin protocols, shows negative indications and should be dropped as a serious proposal.

Hence the issue remains open: What happened and what measures should be taken to mitigate such disruptive problems?

I have something to suggest in this regard but for now I think it is more convenient to close the case with the multiple implementations proposal before proceeding any more.