To simplify the tests that require a different CWD I wrote a context manager that allows to change the working directory. I used it on #3426 to test os.path.abspath() with ASCII and non-ASCII CWDs and realized that it can also be used to fix #5684 where a zipfile fails to extract the content of the archive in the CWD if it is read-only.
Patch attached.

The patch looks good, I'd just move _test_cwd inside the function and drop the [:-3] from TESTFN, but apart from that it's OK. I also agree that functools.wraps should be added.
To summarize the discussion we had on #python-dev:
1) the context manager should always create a writable cwd and to be able to run with -J it should contain the process id. Using TESTFN as first-level dir solves both the issues;
2) a suffix is added to TESTFN to let the tests use TESTFN as a valid filename;
3) the second-level dir is 'tempcwd' by default or can be passed to the function in case a test needs a specific name for the cwd;
The result will be something like '@test_xxxx_tmp_cwd/dirname'.

Different approach, after some other talks with Ezio and David.
Now the directory is changed before running any test.
The developer can assume that the current directory if always writable.
It makes the tests easier to write, and repeatable.
Additionally, TESTFN always contains a single filename (without path).
Before this change, it could be "/tmp/@test" or "@test", which is error-prone.
The decorator becomes useless.

It looks fine.
Few comments:
- "{}_python_{}" could be better, to identify the culprit for leftover directories.
- the warning message may be more specific:
"warnings.warn('tests may fail, unable to switch to ' + name,
RuntimeWarning, stacklevel=3)"
- style guide recommends two spaces after a sentence-ending period

Final version of the patch, with the temp_cwd context manager added to test_support and used in test_regrtest to run the test suite in a temporary directory. It also includes a fix for test_subprocess that was failing when the tests are not run in the original cwd.

The command line used to run the tests is important.
If you run through "test.regrtest", it should "chdir" to a sandbox directory to run the test. If you call directly the test_bufio.py file, it runs in the current directory (as before the patch).
And the permission of the current directory may give a difference in the 2nd case.
Variants:
python.exe -m test.regrtest test_bufio
python.exe Lib/test/regrtest.py test_bufio
python.exe Lib/test/test_bufio.py (fail if home directory is RO)
And another full run:
python.exe -m test.regrtest
Try some of these variants, it may help diagnose the windows issue.
(Note: maybe some antivirus or other software may be related to the race condition described on #7443)

With Ezio's latest patch (sent via IRC), test_bufio still fails and additionally test_mailbox fails.
If I apply the patch on #7443 along with Ezio's patch, everything looks fine. I haven't thoroughly looked at that issue, but on the surface it looks similar (same setup, same result).

Fixed on trunk with r78136.
Before closing this issue, we may apply additional cleanup on regrtest:
- the "sys.path" hack is not needed anymore (no risk of relative imports)
- the hack for sys.argv[0] could be removed too, and use __file__ instead

"Complex is better than complicated... Special cases aren't special enough to break the rules."
The module "regrtest" is complex enough. We don't need to keep useless hacks inside.
It would be more interesting to replace the hack with some words, or an assertion, and understand the real (or hypothetic) issue behind this hack.
Eventually, if we keep these hacks around, it may hide real bugs.