Pierre,
I applied your patch to my local copy of cgi.py for my installation of 3.2, and have been testing.  Lots of things work great!

My earlier comment regarding make_file seems to be relevant.  Files that are not binary should have an encoding.  Likely you removed the encoding because it was a hard-coded UTF-8 and that didn't work for you, with your default encoding of cp-1252.  However, now that I am passing in UTF-8 via the stream-encoding parameter, because that is what matches my form-data, I get an error that cp-1252 (apparently also my default encoding, except for console stuff which is 437) cannot encode \u0163.  So I think the encoding parameter should be added back in, but the value used should be the stream_encoding parameter.  You might also turn around the test on self.filename:

        import tempfile
        if self.filename:
            return tempfile.TemporaryFile("wb+")
        else:
            return tempfile.TemporaryFile("w+",
                                          encoding=self.stream_encoding,
                                          newline="\n")

One of my tests used a large textarea and a short file.  I was surprised to see that the file was not stored as a file, but the textarea was.  I guess that is due to the code in read_single that checks length rather than filename to decide whether it should be stored in a file from the get-go.  It seems that this behaviour, while probably more efficient than actually creating a file, might be surprising to folks overriding make_file so that they could directly store the data in the final destination file, instead of copying it later.  The documented semantics for make_file do not state that it is only called if there is more than 1000 bytes of data, or that the form_data item headers contain a CONTENT-LENGTH header (which never seems to happen).  Indeed, I found a comment on StackOverflow where someone had been surprised that small files did not have make_file called on them.