The problem is quite old. [1] is a 12 year old bug report on this very problem in Mozilla.
That looks like the best solution. The security certificate of the site shows the punycode version of the URL. If the address bar URL and the certificate URL are different, then, at least for addresses in English, that should raise an alarm.
There's a mention below ( https://news.ycombinator.com/item?id=14119826 ) that some browsers will show the IDN in the certificate too, presumably because it would otherwise be equally confusing if they didn't match (they do match.) This isn't a problem that can be solved without showing both the IDN and punycode.
https://en.wikipedia.org/wiki/Cyrillic_(Unicode_block)
From that, you can see domains composed exclusively of those characters with are homoglyphic or nearly so with the ASCII equivalents would be susceptible to this:
AaBCcEeFHhIiJjKMOoPpSsTXxY
That's not all the letters, but there are plenty of domains in English which can be written to look the same with entirely Cyrillic.
Everyone should learn to speak English like normal people, is that what you're trying to say?
There is a set of simple, clearly defined symbols (ASCII) that make up the URL. It must be like that for URLs to be ever secure. If the URL can be made of tens of thousands of symbols, some of which are completely identical, the URL will never be secure.
https://en.wikipedia.org/wiki/Passport#Languages
Simple sanity checks for mixed character urls by the browser easily remedies this.
Except this particular example, the name 'epic' is written entirely with Cyrillic characters. One could argue whether a Russian company has the right to use such a name (with all-Cyrillic characters), or how it would be input --- and if you want it to be easy to input for those who don't completely have IDN support and matching ways to input those characters, you'd have to also display the punycoded version, at which point a transliterated name would be better anyway.
My point/question is more "is the issue actually words in two different character sets creating a collision or mixed alphabet collisions?" If it's the former, I'd like to see more examples to show this is a prevalent issue that wouldn't be caught by a sanity check that catches URLs with mixed character sets. (That is, how many unique words across languages are there that actually get a hit this way, in the same way Epic/Ерис do?)
As for passports, I understand your point on the universal nature of English, but International passports serve a completely different purpose than a domain name. So much of the web is non-english, save the domain name for some of them, and I'm not sure why it has to be this way. If the owners want it that way, great. If they want a domain in the local language, I'm not sure why they shouldn't be allowed to. A passport is meant for a very specific set of people (border guards, law enforcement, airline and other travel employees) to be able to verify your identity. A domain name just needs to resonate with its audience.
I just don't see why every business across the planet needs to compete for the same flowers.com address, or petstore.com, or cars.com. There are plenty of unique words and ways to communicate the same idea, I'm not certain why we need to restrict ourselves to English here. It just makes already expensive domain names even more expensive. If I have a club in San Francisco that I wanna call White Nights, there's no reason that a club in St. Petersburg should have to compete with me for the same name when they have their own term for White Nights, especially when the issue seems to not be about foreign character sets, but mixing character sets in the domain name. All ascii does work, but it's a grenade for an anthill.
Edit: an aside, I didn't realize that Safari translates to punycode. Very cool.
There's already a .ru domain. And why would it want petstore.com instead of zoomagazin.com? Everyone is able to transliterate to Latin here. Many years have passed since .рф was introduced and almost nobody is using domains in Cyrillic. Sites that use Latin domains are much more popular. At this point it's safe to say that non-ASCII domains is a feature that nobody really needed (except for phishers, of course).
I don't see this as being an easy or even solvable problem in general --- after all, a Russian IDN registrar could rightly argue that it should be valid to use all Cyrillic characters in IDNs; but at least for those of us who are content with English-only domain names, we can just disable IDN.
I suppose one solution would be, when IDN is detected, to show both the Unicode and Punycoded versions:
[www.xn--e1awd7f.com]https://www.epic.com/
One could also argue that this is also a usability feature, for easy copying of IDNs by those who otherwise cannot write them.