We currently do this, synchronous, on a delete db call;
1) close the file descriptors
2) remove the db from the internal ets tables (lru, etc)
3) rename the file to a different directory and name.
4) A fire-and-forget process is then spawned to delete the file.
On startup, couchdb deletes everything in the .deleted directory.
Spawning a process without waiting for it to complete is perfectly fine if there's nothing to be gained from waiting, as is the case here.
I don't see what would be achieved by blocking for the deletion like we used to.