The rest of the code has clearly never had its deficiencies exposed on Windows, simply because executable() has prevented that.  So what the rest of the code "already supports" is basically nothing.  Reasonable Windows support is appropriate to implement as part of the bugfix.

You state that it isn't the function of http.server to extend Windows, however, even MS IIS has extended Windows to provide reasonable web scripting functionality, albeit it its own way, thus convicting the Windows facilities of being insufficient.  Attempting to use http.server to get a web testing environment running so that Python scripts can be tested locally requires some way of using an existing environment (except, of course, for "all new" web sites).  I suppose you would claim that using http.server for a web testing environment is an inappropriate use of http.server, also.  

Yet http.server on Unix appears to provide an adequate web testing environment: yes, some of that is because of Unix's #! feature.  This would certainly not be the first case where more code is required on Windows than Unix to implement reasonable functionality.

My desire for support for Perl is not an attempt to convince Python developers to use Perl instead of Python, but simply a reflection of the practicality of life: There are a lot of Perl CGI scripts used for pieces of Web servers.  Reinventing them in Python may be fun, but can be more time consuming than projects may have the luxury to do.

Your claim that it already supports Python CGI scripts must be tempered by the documentation claim that it provides "altered semantics".  "altered semantics", as best as I can read in the code, is that the query string is passed to the Python script as a command line if it doesn't happen to contain an "=" sign.  This is weird, unlikely to be found in a real web server, and hence somewhat useless for use as a test server also.

http.server has chosen to use subprocess which has chosen to use CreateProcess as its way of executing CGI.  There are other Windows facilities for executing programs, such as ShellExecute, but of course it takes the opposite tack: it can "execute" nearly any file, via registry-based associations.  Neither of these seem to be directly appropriate for use by http.server, the former being too restrictive without enhancements, the latter being too liberal in executing too many file types, although the requirement that CGI scripts live in specific directories may sufficiently rein in that liberality.

However, you have made me think through the process: it seems that an appropriate technique for Windows is to allow for a specific set of file extensions, and permit them to be executed using the registry-based association to do so.  However, for .cgi files, which depend heavily on the Unix #!, emulation of #! seems appropriate (and Windows doesn't seem to have an association for .cgi files either).

Your suggestion of making CGIHTTPRequestHandler easier to subclass is certainly a good one, and is almost imperative to implement to fix this bug in a useful manner without implementing an insufficient set of Windows extensions (for someone's definition of wrong).  There should be a way to sidestep the "altered semantics" for Python scripts (and Python scripts shouldn't have to be a special case, they should work with the general case), without replacing the whole run_cgi() function.  There should be a hook to define the list of executable extensions, and how to run them, and/or a hook to alter the command line passed to subprocess.Popen to achieve same.

So is_executable and is_python both seem to currently be replacable.  What is missing is a hook to implement cmdline creation before calling subprocess.Popen()  (besides the other reported bugs, of course)