> Wouldn't it be possible to amend PEP 3333?

Sure...  except then it would also be necessary to amend PEP 3333, and also all WSGI applications already written that assume this, any time in the last nine years.

This is a known and intended consistent property of how WSGI handles HTTP headers.  Under Python 2.x, PATH_INFO was a byte string (and still is), and to maintain also side-compatibility with Jython and IronPython, header strings are always maintained as "bytes in unicode form", with applications having responsibility to decode-recode as needed.

This isn't a minor corner of the spec, it's central to how headers are handled, and has been so long before Python 3 even existed.  To mess with it now means you break applications and frameworks that are already correctly written to follow the specs.

To put it in brief, the reported behavior is not a bug, it is a feature and by design.  A server that returns a UTF-8 decoded PATH_INFO is in violation of the spec, so the reference implementation of the spec should absolutely not do so.  ;-)