So should those with accented characters, but those can easily be used for phishing. It would be arguably unfair to allow Chinese and Japanese characters but not allow accent marks. Perhaps only partially supporting international characters would be better than only supporting ASCII, but that's the status quo.
The letter "c" can also be used to "phish" people who want a domain name that should include the letter "o" and yet we don't say the letter "c" is disallowed :/. The premise of domain names being your source of security is what is broken: we should be helping end users by scoring domains based on some combination of page rank and a web of trust implicitly built out of their existing address books, so when they are sent to bankcfamerica.com it shows up as "likely a wrong URL" without them having to squint at the domain name to notice the "c" (at which point we can probably also replace domain names with a post-scarcity collision-tolerant naming system, which would be absolutely glorious).
Even after accessing the link from HN the domain looks exactly the same in my browser.
Even if it is punycoding, I’m not sure how one would distinguish the actual domain from the coded one (unless you know the specific format convention that punycode follows).
DNS is generally restricted to a subset of the ASCII character set. While this isn't a strict limitation of DNS, there are enough DNS servers, clients, and applications using DNS that break on non-ASCII sequences that it's a de-facto standard.
In place of storing Unicode inside DNS, Unicode sequences outside RFC 952 (ASCII alphanumerics, case-insensitive, along with '-' and '.' characters) are encoded into RFC 952 compatible hostnames using Punycode, and stored thus in DNS.
Here in HN comments, Unicode is just embedded as actual UTF-8, no strange DNS encoding needed. The hostname, however, is actually xn--gckvb8fzb.com, hence why it's displayed as such.
(your browser will automatically convert from whatever encoding to Punycode where appropriate, so a link like https://xn--gckvb8fzb.com (should) work correctly, but the actual hostname lookup performed on the wire is for xn--gckvb8fzb.com)
Edit: well, HN also converts my Unicode hyperlink into the punycode equivalent. Interesting. It preserves the original encoding when I go back to edit the comment, but displays the Punycode form everywhere else. This gives credence to the idea this is intentional to avoid homoglyph attacks, as csnover states.
The punycode representation of the domain name is the “true” representation, HN just doesn’t detect that and convert it from punycode to Unicode. This may be unintentional, or it may be to avoid homoglyph attacks.
That said, Chrome supports them both. here's cañon.com (which is just a parked site): http://xn--caon-hqa.com/ There is also http://xn--ms-mia.com/ (más.com) which redirects.
I know Chrome has done some stuff to prevent problems and understand when people just make the easy choice and show the punycode though.