What I've learned from email newletters is that Microsoft Outlook needs to die a swift and horrible death.
There is absolutely no good reason why we should have to create email newsletters that require tables for layout.
I can imagine the same thing being done to email, where modern features could be built on top of email, which just gracefully degrade if those features aren't available in the client (e.g. something similar to inline source maps, which can decorate parts of the email for clients that support it, but are otherwise out of view for clients that don't). If the feature is useful enough, other clients will adopt them, pushing the protocol forward.
The problem is that people who send email need it to look a certain way, and leaving older clients behind, just like you'd have done in IRC/mIRC, is not an option. So having the option to use modern features doesn't change anything, at least for email.
I think it's fair to say that actual people don't need any of this. It's businesses and advertisers that would be the overwhelming consumer of these abilities.
As a person who receives email, I would really prefer the people who send email not to have this ability.
There are dozens of apps like this. The most straightforward example is probably Redkix.
[1] https://mobile.nytimes.com/2010/11/25/technology/personaltec...
Also, please use text/markdown instead of inventing yet another weird markup. Bonus points if it's CommonMark (which is much more strictly defined and thus guaranteed to look the same across renderers).
One of my projects over the last couple months for FWD:Everyone has been stripping tables from commercial emails while keeping their content and trying to preserve a comparable layout while just using paragraph tags and other simple markup. It's an interesting challenge, given that tables can be recursively nested inside cells in all sorts of different combinations. You'd think that it wouldn't even be possible to do this and get the ordering of block elements right, but it actually seems to consistently work for tables with mostly text content.
In our case the reason we did this because we want to format emails in a consistent way to make them readable, and also it's easier to guarantee that our redaction tool is properly redacting content when we limit ourselves to a fixed subset of HTML.
In a dream world Microsoft & Apple could partner together on this and create a better set of standards...
The type of element is less important than there being consistency and documentation.