My problem with all these is simple: unlike dealing with people's names which, for the most part, they did not choose and have legitimate cultural reasons for the presence of special characters therein, it's not my problem if someone wants to register on my site with an (RFC-compliant!) email like @1st.relay,@2nd.relay:[email protected] or a quoted email like (following payload is unquoted, quotes you see are part of the email address) "<>"@netmeister.org

I am going to put a (sane and reasonable) maximum length for email addresses on my postgres db column so it's not stored in TOAST; I don't care if you're technically allowed 256 bytes before the @ sign: I'm not wasting space in my database so you can feel special.

I do validate that the domain not only resolves but that it also has a valid MX record because this benefits ~100% of my users and protects them from their typos. It's not my problem if you want to register for my service before you set up your nameservers - its yours.

etc, etc, etc.

It's a fun thought experiment but there's no way in hell I'm going to advise any company to actually allow any of these and open themselves up to a can of worms.

A more sane list of rules would be things like "make sure you support - in the prefix or the domain" and others of its ilk. Also, I came across an email address that was created automatically from Active Directory to Azure with the apostrophe preserved (think "Sean O'Henry" turned into "sean.o'[email protected]" and it blew my mind when that "just worked" in testing. These would be helpful rules because you'll actually encounter them in the real-world and not supporting them will genuinely inconvenience real people and not someone's PhD research.