> Isn't this just "how windows behaves" on some filesystems with 
> little that we can do about it?

The suggestion was to include an error handler that retries unlink() and rmdir() -- particularly rmdir() -- a given number of times, probably with an exponential back off, before giving up and failing. This accounts for race conditions in which the delete succeeds but the file/directory can't be unlinked because it's currently open (with delete sharing). A lot of these cases are similar to ReadDirectoryChangesExW(), in which the owner of the open is immediately notified that the directory was deleted. If they're well behaved, like Explorer, they immediately close their handle to allow the directory to be unlinked by the system. But that may not be soon enough for the process that deleted the directory. The suggested retry loop would help to work around this race condition. A couple people were in favor of this being provided by the standard library, so everyone isn't forced to implement there own workaround for a common problem.