the biggest barrier, in my opinion, is the ugly punycode links. most browsers still do not render them properly, and if they did, it would have false positives. (i.e. there is no way to tell if a string is intended to be punycode or not)
Meanwhile, almost all of humanity still can't get decent urls in their native language :(
Why not?
For example, http://xn--h1alffa9f.xn--p1ai/ renders the URL in Russian for me in the URL bar in all of Chrome, Firefox, and Safari (though Chrome converts to punycode if I copy the URL from the URL bar, unfortunately). [Edit: Also, it looks like HN's linkifier converts to punycode; what I wrote there is "россия.рф" and that's what HN has stored if I edit this comment.]
In more detail, for Firefox (where I can find this sort of thing quickly in the code), there are the following things affecting the display:
1) The "network.IDN_show_punycode" preference. This defaults to false, so punycode is not forced across the board.
2) There is a bunch of preferences for what toplevel domains are "safe" for use with non-ASCII chars by default no matter what. That option currently defaults to "false" as far as I can tell.
3) URLs the fit in the Highly Restrictive profile defined at https://www.unicode.org/reports/tr39/#Restriction_Level_Dete... are shown as non-punycode as far as I can tell.
4) There's some heuristic detection for URLs using multiple scripts at once and blocking that.
There are also preferences to force-allow or force-deny use of IDN with certain characters; those sets are empty by default.
In any case, the default behavior looks to me like a single-script URL in any language would be shown in IDN. Do you have a counter-example?
https://searchfox.org/mozilla-central/rev/75294521381b331f82... has the relevant preferences with their default values as of today.
Disclaimer: I work on Firefox, and have been involved peripherally in some of the IDN work.