I don’t understand how your client can solve for someone else sending you top-quoted replies, or word-html-engine compatible HTML designed to work in outlook. Or eighty other people hitting reply all on the email chain you’re on. The clients other people use can behave completely differently, because the protocol leaves so many decisions up to clients.
You're adding things not in the OP list I was responding to so I didn't claim that. But let's try:
Reformatting top-quoted replies. This is possible with email because you can pipe the messages through any preprocessing you want. Inserting custom processing into the delivery pipeline is generally impossible with all proprietary systems, but easy with an open standard like email.
HTML formatting: Again, easy due to customizable preprocessing and/or viewers.
Eighty people responding to a thread: This is threading, handled natively by most good email clients. Gmail makes a mess of it though, so I get why it'd be painful if you use gmail. Don't use gmail.
> because the protocol leaves so many decisions up to clients.
I feel like this is a misunderstanding. The clients have nothing to do with the protocol (SMTP), that's the job of the MTAs (mail transport agents).
The client provides the UI/UX interaction part. It is an immense strength of standards like email that there are tons of clients. You may want a completely different UX with your email than me, so you're free to have it exactly the way you want and so am I. And we can still message each other. This is impossible with proprietary walled gardens.
Client support for the features you’re talking about has everything to do with the protocol. How are you threading if not based on SMTP headers? What SMTP headers are meaningful for threading? What does SMTP have to say on the subject? Nothing - because it only talks about MTA behavior not clients.
