The Windows DeleteFileW API which is used under the covers of java.io.File::delete does not always guarantee an instantaneous deletion of a file. When there are handles open to the file, it'll set a delete on close flag and defer deletion to a point when the last open handle is closed.

With the following 2 tests an issue can be demonstrated which will result in a test failure:
jdk/modules/scenarios/automaticmodules/RunWithAutomaticModules.java
jdk/modules/scenarios/overlappingpackages/OverlappingPackagesTest.java

The problematic behavior in the tests is that the first test (RunWithAutomaticModules.java) would create a jar file to be used on the module path. Due to some compilation operation, I think the process keeps the handle to the jar file open. When the next test (OverlappingPackagesTest.java) is run (in the same VM that still holds the open file handle), jtreg tries to empty the scratch directory and thinks it is successful. But then the test stumbles over a zombie file which is still there and cannot be accessed.

The issue can only be demonstrated in agentvm mode because only then the VM that holds a lock to the jar file stays active and blocks the depletion of scratch.

I run this jtreg commandline to enforce one test VM job:
jtreg -v:summary -agentvm -conc:1 -a -ea -esa -ignore:quiet

For sure, the tests can be modified (probably one should look why the handle to the jar file is not released). However, jtreg should also be made more reliable in terms of guaranteeing an empty scratch directory.