Possible bug dealing with deletions

Nobody has claimed this yet.

I'm writing a recursive delete algorithm, which looks like this:

```js
function recurseDelete (archive, targetPath, st) {
return co(function* () {
// fetch stat if needed
if (!st) {
st = yield stat(archive, targetPath)
}
if (st.isFile()) {
// delete file
return new Promise((resolve, reject) => {
console.log('unlink', targetPath)
archive.unlink(targetPath, (err) => {
if (err) reject(toBeakerError(err, 'unlink'))
else resolve()
})
})
} else if (st.isDirectory()) {
// fetch children
var children = yield readdir(archive, targetPath)
// delete children
yield Promise.all(children.map(childName =>
recurseDelete(archive, path.join(targetPath, childName)))
)
// delete self
return new Promise((resolve, reject) => {
console.log('rmdir', targetPath)
archive.rmdir(targetPath, err => {
if (err) reject(toBeakerError(err, 'rmdir'))
else resolve()
})
})
} else {
throw new Error('Unexpectedly encountered an entry which is neither a file or directory at', path)
}
})
}
```

That's being run against the following file-tree:

```
a
b/ (dir)
b/a/ (dir)
b/b
b/c
b/d/ (dir)
b/d/a
b/d/b
b/d/c/ (dir)
b/d/c/a
b/d/d
c/ (dir)
c/b/ (dir)
```

Specifically against the `/b` folder. A working log would look like this:

```
unlink b/b
unlink b/c
rmdir b/a
unlink b/d/d
unlink b/d/a
unlink b/d/b
unlink b/d/c/a
rmdir b/d/c
rmdir b/d
rmdir b
```

But the log I get is this:

```
unlink b/b
unlink b/c
rmdir b/a
unlink b/d/d
unlink b/d/a
unlink b/d/b
unlink b/d/c/a
rmdir b/d/c
Error: File not found
```

For some reason, `rmdir('/b/d/c')` is failing with File not found. If I run the entire method on the '/b/d' folder, no such error occurs!

I'm wondering if the record of the '/b/d/c' folder is getting lost somehow?

Start with the recursive delete algorithm in the issue and reproduce it against the shown tree, specifically deleting /b and comparing the expected and observed logs. Trace the operations around b/d/c and the append-only tree state to determine why rmdir reports File not found. Done means recursive deletion of /b completes without the reported error and preserves the expected operation order.

Written by the indexing model from the issue text.