1. Call the protocol "Email 2"
2. Build something that actually justifies the name
I'm only half joking; the messaging around the protocol is almost as important as the protocol itself. iMessage is a good example of how to expose something like "Email 2" to the end user: as a seamless upgrade, indicated by a subtle UI element, when a client happens to negotiate the upgraded protocol with the server.
Enabling incremental upgrades to infrastructure is critical, but strict backward-compatibility isn't necessarily so. As long as the architecture of the new protocol makes falling back to IMAP/SMTP straightforward when an upgraded client or server isn't available, Email 2 doesn't have to be able to talk directly to legacy.
There's certainly a chicken-and-egg problem in driving enough server adoption to get client vendors to add support while driving enough client adoption to get server operators on board, but there's probably a sweet spot between making a clean enough break with legacy tech that it's more straightforward to implement, while making it conceptually similar enough that it can still plug into the same patterns.
The problem with that approach is that as long as 0.01% still uses the old protocol, you can‘t get rid of it. And then you have a bag with the old and new protocol and maybe after 20 years you realize it‘s going to take another X years until you have at least some relevant adoption, as demonstrated with IPv6.
If one is ever going to „replace“ email it happens on top of the existing protocols and not as a replacement.
This sort of thing could be deployed by people in addition to the other services. For a while and perhaps a long while it’ll be fringe. But if there’s enough utility to it then it may just catch on.
It is backward compatible, smtp, imap, pop3 and support unicode email as well, and it is REST API callable. So you can receive and send email.