Ah, never mind, the parser spec didn't change and still requires non-UTF-8 charset support. https://html.spec.whatwg.org/multipage/parsing.html#character-encodings

Unable to reproduce this issue on reported version 63.0.3235.0 using Windows 10 with steps mentioned below.

1.Naviagted to https://euckr.herokuapp.com
2.Opened devtools and searched for UTF and found <meta charset="utf-8">. Attaching screenshot for reference.

@Reporter: Could you please confirm whether the steps mentioned are correct or not??

Thanks in advance!! 

Deleted: Issue 772714.png 64.7 KB

	Issue 772714.png 64.7 KB View Download

That fragment of the HTML standard is for authors/authoring tools, not a normative description of how page encoding is determined.

It's not web-compatible to drop support for legacy encodings, unfortunately. Which is why HTML and Encoding spend so much time describing how to determine the encoding of documents.

To be clear, the phrase "Regardless of whether a character encoding declaration is present or not, the actual character encoding used to encode the document must be UTF-8." must be read within the later context:

"If an HTML document does not start with a BOM, and its encoding is not explicitly given by Content-Type metadata, and the document is not an iframe srcdoc document, then the encoding must be specified using a meta element with a charset attribute or a meta element with an http-equiv attribute in the Encoding declaration state."

And again, as an authoring requirement, UTF-8 is mandated. Implementations still need to handle legacy encodings, though.