I see that the first test that failed was AutomaticIndexStatisticsTest.testStatsCreatedOnGrowthThenDeleteDb. The problem was that one of the data files in the seg0 directory could not be deleted. Since all the other files got deleted, this is now basically a very corrupt database... Derby is not, or rather has not been made, capable of deleting an existing directory structure in the default case, and thus all tests accessing the default database wombat fails.
Again this intermittent delete issue causes trouble, and I believe it happens only on Windows. I've seen something similar with the upgrade test on my machine (Windows Vista).
I'm not sure if the istat daemon can cause Derby to keep file handles open after shutdown, but maybe it can if the timing is right (i.e. calling a path that involves reopening a container if it has already been closed).
I see at least two ways to progress on this problem:
a) Make the delete method more persistent by adding a sleep after the first iteration of deletes, and then try to delete all remaining files in a second pass. Could also repeat if required. If the files cannot be deleted after X iterations, there must be a real resource handling bug.
b) If easily reproducible, debug to find out if there are open file handles and if so figure out why. I don't know if you can easily map a file handle to something inside the Java process though, so this may involve a fair amount of code inspection and debugging.