Message8250

I've been experimenting with this on 2.7b and with other Java versions. Java 6u45 fails in this way but 7u45 passes.

There are good release notes about this for 7u21, and in 7u25 Oracle introduced a property to suppress the fussy behaviour.
http://www.oracle.com/technetwork/java/javase/7u25-relnotes-1955741.html

6u45 is roughly contemporary with 7u21 and has the same check.
http://www.oracle.com/technetwork/java/javase/6u45-relnotes-1932876.html

The puzzle, then, is why these tests pass on 7u45.

subprocess.py does an apparently correct job of looking for special characters and escaping them to conform to the Windows runtime API. The problem may be (may have been) that the new feature in ProcessBuilder for Windows did not take proper account of the escapes. Stepping through ProcessBuilderImpl in 6u45, that seems to be the case.

Oracle appear to have had second thoughts about this checking. Since 7u40 it is now in effect only when a security manager is set. The small print of the release notes for 6u40 leads to:
http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8016046

It is perhaps still an issue for applications that use a security manager, and cannot choose (at the application level) to use the CMD /C form. But I'm not sure we should force use of CMD /C in the library, since this is meant to be under client control through the shell argument to subprocess.call() and Popen().