Gunicorn is a gateway so it shouldn't have a strong opinion about the transfer encoding. I think it's better to only test if the transfer encoding header is chuned or not.

if value.lower() == "chunked":
  chunked = True

and let it pass for other cases

This removes the need of UnsupportedTransferEncoding also

Your proposal can still be attacked by the following desync:

Content-Length: 5
Transfer-Encoding: chunked
Transfer-Encoding: Identity

Most proxy will use the chunked, but we will use the CL.
My understanding of Transfer-Encoding is that its a hop-by-hop header, meaning that we should parse it, use it and strip it before passing the data down the line.
For example, AWS ALB will not accept anything that is not identity or chunked. If you read my improvements section above, I suggest that we do something similar to other WSGI server: parse the request to the best of our ablity and only transfer data to the application using a CL. We do buffer the data in this application anyway and we don't support gzip, compress and deflate.

reading a bit more about PEP333. It says: WSGI servers must handle any supported inbound "hop-by-hop" headers on their own, such as by decoding any inbound Transfer-Encoding, including chunked encoding if applicable. There is a great thread here to read: pallets/flask#367

Gunicorn has a long history of supporting chunked encoding and last 20 is having the support of wsgi.input_terminated, i'm not inclined to change this actually.

if I understand your concern, in the case of your example

Content-Length: 5
Transfer-Encoding: chunked
Transfer-Encoding: Identity

TE should be Identity and not chunked? Or do we want it to be chunked (which is really weird).

My main concern is to make sure we support the last TE given whatever it is (there are other cases than "Identity" in some apis), so we must not return an error, if it's different.