I'm pretty sure that whatever PM sense (proper UTF8 encoded responses or whatever), have no effect on what the Content-type has for charset and encoding attributes. A website can set the Content-type charset and encoding attribs to whatever. That is independent of what they send in the content stream. I.e. Doing one doesn't force the other. They can both be done independently -- however, having them in agreement might be less confusing to some browsers.

Likely what is so, is that those who are interested in UTF8 set their browsers to assume that encoding for pages that don't declare an encoding since many HTML4 websites that don't declare encoding still use UTF8 on their website -- whether by intention or by users typing in UTF8 strings that later get displayed to others. I.e. when we use UTF8, most of us see it properly as UTF8 chars on our browsers, already. What is at issue is that the code blocks convert such things into html-enties when it scans our input into the site, but it doesn't convert them on output because they are in code blocks.

The bug is that they are converted into HTML-entities in the first place.

Too bad no one is interested in fixing this. I guess they went AWOL... ;-)