In the end it's a governance problem. If you create an ecosystem which sets a precedent of taking security seriously and thoroughly excommunicating insecure clients, netsplitting them out of the mainstream, then I think you'd see a lot more interest in client vendors and users routing around obsolescence and upgrading to whatever the current best practices are. This is particularly nice if the protocol is designed to let you enforce this, by ratcheting up to new versions.
Email never had this, and it shows. SHA-1 in HTTPS is a kinda intermediary example; browser and server vendors have been petrified to break legacy systems and generally not accorded that much priority to security updates. In Matrix, we hope to avoid this by setting a precedent that if Olm/Megolm is found broken tomorrow, we'd work with the major client authors to upgrade them, patching their clients ourselves if we have to, or providing a localhost shim or whatever, and then take the biggest community anchor points (e.g. #matrix:matrix.org) and throw the switch to the new protocol, and make it abundantly clear that folks on old clients have been left out in the cold for security reasons and need to get upgraded immediately. If you're a big enterprise with a private deployment who doesn't want to upgrade rapidly, that's fine. But the societal pressure will enormously be to get with the program and upgrade. Let's see how well that works though - we haven't really had to make any backwards incompatible changes yet since we started in Sep 2014.
(p.s. hi! :D)
