Can please attach a screencast to this report, what you exactly enter into the Omnibox to reproduce the issue? Thanks in advance.

It's punycode https://en.wikipedia.org/wiki/Punycode

Able to reproduce the issue on mac 10.13.6 using chrome reported version #70.0.3538.77 and latest canary #72.0.3608.0. Issue is specific to OS-mac.
This is a non-regression issue as it is observed from M60 old builds. 
Hence, marking it as untriaged to get more inputs from dev team.

Thanks...!!

Mac triage: over to jdonnelly@ for omnibox triage :)

CC meacer@ for his opinion

I know the omnibox dropdown is not a security service.  Nonetheless, I'm curious what you think we should do here:

If a user types / pastes a punycode URL, should we render it as punycode always?  Or maybe render it sometimes as punycode and sometimes not.  The first option is more UI-friendly.  The middle ground might be able to be done based on whether the omnibox--if the user was on the page itself--was rendered as punycode or not.  Or maybe we should always display punycode, as that clearly prevents users from being social engineered to typing / pasting a URL into the omnibox that can led them somewhere strange.

(For the reference, this is not as far as I know an issue with URLs the user visited before.  If I'm wrong on this, please file a new bug.)

IMO this is expected.

If you end up navigating to the URL in question (ÿoutube.com), the omnibox will display it as punycode because it doesn't pass UrlFormatter's spoof checks. So the suggestions UI is showing what the omnibox will eventually show.

Note that this doesn't happen with all punycode domains. If UrlFormatter determines that it's safe, both the omnibox and suggestions will display the domain as unicode instead (e.g. http://xn--41a.ws).

Oh, so we're already doing the middle ground and this is working as intended. :-)

Great!