Why do I have to cd out of a deleted directory?
To me the "cd ../code" is a noop. I'm very interested into hearing why it isn't.
Because files and directories are fundamentally filesystem inodes, not names -- this is perhaps an implementation detail specific to the filesystem type, but it is true for all the ext systems, so I'll stick to it here.
When a new directory code is created, it is associated with a new inode, and that's where it is. There is no record kept of previously deleted files and directories, so there is no means by which the system could check what inode it used to occupy and perhaps shuffle things around so that it is the same again; such a system would quickly become unworkable, and in any case, it is probably no guarantee that you would be back there again -- that would be sort of undesirable, since it means you could also accidentally end up somewhere else if a directory is created that takes your (currently unused) inode.
I'm not sure if this last possibility exists, or if the inode of the deleted directory currently assigned to your present working directory is tracked so that nothing will be assigned to it for the duration, etc.
Your shell doesn't every time do a cd to the path that it was in during the last command, before executing the next command.
You deleted the current directory and created a directory with the same name, which is not the same directory, just something with the same name/path.
File browsers like Nautilus and Windows Explorer normally "go up" the directory tree if a directory gets deleted on a local file system. However this is not always true for networked file systems, in that case sometimes the deletion does not get noticed and the reappearance could have you ending up in the new directory.
A shell could cd into the current directory before executing the next command, I am not aware of any that do (or can be configured to do so).
On most UNIX-like systems, the "current directory" for a process is stored in the kernel as a file descriptor pointing to that directory. The kernel doesn't actually store the path of the current directory: that information is tracked by your shell.
A filesystem object (file or directory) is only destroyed for good when all filesystem links to it are gone, and there are no file descriptors pointing to that object.
So, if a directory is removed while there's still a process holding it as its current working directory, the process's cwd will keep the directory from being truly deleted. The filesystem links that anchor the directory (its entry in the parent directory, and all of its contents) will be gone, but the directory itself will continue to exist as a sort of "zombie". Meanwhile, you can create a brand new directory at the same location as the old one, which is a completely different filesystem object but which shares the same path.
Thus, when you do cd ../code (or, on many shells, cd .), you are actually traversing the filesystem hierarchy and going to the new directory that resides at the old address.
By analogy, removing a directory would be like forcefully moving a house to the garbage dump (breaking ties to the previous address). If there was still someone living there (using it as their cwd), they'd have to leave before the house could be razed. In the meantime, a brand-new house could be built at the old address.