"Fake" symlinks in /proc. For example, /proc/PID/root/some/path is not necessarily the same as $(readlink /proc/PID/root)/some/path (there might be no other valid path that points at /proc/PID/root, when you have mount namespaces and e.g. yours have that directory shadowed by a mount).
`mkdir -p` failing with `No such file or directory` due to a dangling symlink in the requested path.
Potential effects of `cd .`: filesystem gets asked to resolve the path again, because shell actually does sth like `chdir(getenv("PWD"))` in that case.
Related: when you move a directory that's above some process's working directory, that process's working directory moves, but if it keeps track of its working directory path (like shell does) that will become desynced.
Writing to a mountpoint before the filesystem gets mounted, ending up writing "behind" the mountpoint, and being very confused where the files ended up (in rootfs in the mount directory, but its contents is normally invisible when something is mounted on top).
@b0rk BTW I think the parent post didn't federate to your instance (not sure why; length? happenstance? some problems caused by your question having been edited?) and I think no one else mentioned the /proc/N/root trap.