We chose it because it was easier to implement and we couldn't see
that doing so would cause undo hardship.  Rsc's observation is good
but wasn't really a design goal.

There are 3 obvious alternatives:
- Unix' solution of making the remove fail with "file busy"; it was
always inconvenient and confusing.  They use that one for in use
executables.  The fs doesn't really know when a file is executing so that
one isn't really that useful to us.
- Have the remove work but not really remove the file from the directory
till the current opener goes away.  That's just too confusing.
- Disassociate the file with the directory, but leave it around for anyone
that has it open to keep playing with.  This is easy to do when the
file is really represented by an inode that doesn't have anything to
do with a directory.  It's a lot harder without that indirection.  We
didn't have inodes.  The best we could do is copy it somewhere else
and fudge up pointers to the somewhere else (a special invisible
directory perhaps).  It also leads to cleaning up orphaned files
during a reboot of the file server, fsck's job (or one of many) in
Unix.  It gets messy quick without inodes being the one true
representation.

Clearly its a matter of taste; with enough code you can do most
anything.  If it were a goal, Ken would proabably have designed
his fs a bit differently.  Our taste, like our minds, tends to
favor the simple.  Of course, we're gradually losing our sense
of taste due to exigency. About time for a new simple operating
system.