This suggestion hints at some serious misunderstandings.
Firstly, under normal circumstances two processes cannot interfere
with each others' internal states (*1) - and yes, every process has a
/separate/ current directory as part of its internal state.
/Most/ of that internal state is copied from its parent when it
starts, which gives the illusion that the shell is changing things in
its children, but in reality, it's setting their starting conditions,
and cannot influence them thereafter.
Secondly, /most/ commands that you type into a shell are separate
programs, not part of the shell. Moreover, the /terminal/ is a
separate program from the shell, and they can only interact through
the tty byte stream.
Thirdly, the kernel tracks the current directory on behalf of each
process. It tracks the directory by its identity, /not/ by its name.
(*2) This means that you can do this:
$ mkdir /tmp/a
$ cd /tmp/a
$ mv ../a ../b
$ /bin/pwd
/tmp/b
Note that as an efficiency measure, the built-in /`pwd/` command and
the expansion `/$PWD/` give the answer cached by the most recent /cd/,
so this should be considered unreliable:
$ pwd
/tmp/a
$ cd -P .
$ pwd
/tmp/b
For comparision, caja (file manager in MATE) is stepping back as
many directories as needed when it is located in a directory that
is deleted in bash or caja.
Comparing programs with dissimilar purposes is, erm, unconvincing.
Caja's /first/ purpose is to display information about a filesystem.
To make this more comprehensible to the user, it focuses on one
directory at a time. (*3)
Critically, every time you make a change, it shows you the results
before you can make another change.
That is pretty much the opposite of a shell.
Bash (like other shells) is primarily a scripting language and a
command line interface, whose purpose is to invoke other commands
(some of which may be built-ins (*4)). The shell is supposed to /do/
things /without/ showing you what's happened. If you want to see the
new state of the system, you ask it to run a program such as `/pwd/`
or `/ls/` to show you. (*5)
Currently if a program is invoked in an unlinked current directory,
most likely it will complain but otherwise do nothing.
But if the shell were to surreptitiously change directory, a
subsequent command invoked in an unexpected current directory could
wreak havoc, including deleting or overwriting the wrong files or
running the wrong programs, and with no guarantee that there will be
any warning indications.
All that said, if you want to risk breaking your own system, feel free
to add the relevant commands to `/PROMPT_COMMAND/` as suggested by
other folk.
-Martin
*1: Okay, yes there are debugging facilities, but unless the target
program is compiled with debugging support, attempting to change the
internal state of the other program stands a fair chance of making it
crash instead. You certainly wouldn't want "rm" to cause your
interactive shell to crash. And there are signals, most of which
default to making the target program /intentionally /crash.
*2: Linux's //proc/$pid/cwd/ reconstructs the path upon request. Only
when it's deleted does it save the old path with "(deleted)" appended.
*3: It's not even clear that this focal directory is the kernel-level
current directory of the Caja process, but it probably is. I would
have to read the source code to verify this.
*4: mostly /regular/ built-ins that behave as if they were separate
programs; not to be confused with /special/ built-ins, which can do
things to the shell's internal state.
*5: Even if the shell's prompt includes its current directory - which
isn't the default - it could be out of date by the time the user
presses /enter/ on their next command.