I put together a trivial patch against the 2.7 trunk (basically: I added
a os.rename before the os.remove in test_support.unlink) and reran my
test harness with test_zipfile... and it still failed because, of course,
test_zipfile calls shutil.rmtree which bypasses the test_support.unlink
altogether etc. etc.

At this point several things occur to me:

1) There's little point in targetting the 2.x tree since 2.7 is due
out any time now and is effectively end-of-line for 2.x and this
isn't a release-blocker. Therefore whatever effort is brought to bear
should be against the 3.x latest

2) This is a repeatable but relatively minority case: it only applies
to Windows boxes and only to those where some behind-the-scenes process
is holding this kind of lock on files for long enough to affect the
tests. I'd certainly like to nail it but...

3) The amount of work -- and intrusion in the tests -- is quite substantial.
Just looking [*] for straight os.unlink instances, without even considering
shutil use gives 71 instances; os.remove gives another 90. That's even
without the issues of the tests for shutil and os in any case.

I'm willing to do the legwork of moving all the tests use, eg, support.unlink,
support.rmtree and so on, but quis custodiet? who'll test the tests?

grep "os\.unlink" *.py | wc -l
grep "os\.remove" *.py | wc -l

4) All that said, the result should be a cleaner, more controllable test environment,
at least for temp files. Another solution would be to rework the use of
TESTFN on Windows to use a new temporary file every time. But that would be as much
work and more than the unlink / rmtree work above.

I'd like to hear opinions before I move forward with a non-trivial patch
for this.

For the sake of completeness, I attach a tiny test case which shows that the
rename/remove approach should in fact work for the symptom we're seeing.