Describe the bug

toolbox enter changes to the home directory only when the current working directory path does not exist in the container. However many paths in the container are to a different directory that in the host (different in the sense of having different contents and inode).

It's confusing enough that container and host filesystems are different but with some directories shared/mounted. It probably makes confusion worse acting like nothing unusual has happened when directory contents and inode silently change even though they have the same path.

Steps how to reproduce the behaviour

1. cd /var
2. ls -id .; ls
3. toolbox enter
4. ls -id .; ls

Expected behaviour
A message and/or a change to home directory in the container.

Actual behaviour
Nothing unusual, as though the user is still in /var of the host.

Output of toolbox --version (v0.0.90+)

[castedo@nasa ~]$ toolbox --version
toolbox version 0.0.99.2

Toolbox package info (rpm -q toolbox)

[castedo@nasa ~]$ rpm -q toolbox
toolbox-0.0.99.3-0.4.module+el8.5.0+12682+a4eeb084.x86_64

Info about your OS

[castedo@nasa ~]$ cat /etc/os-release 
NAME="Red Hat Enterprise Linux"
VERSION="8.5 (Ootpa)"
ID="rhel"
...

Additional context

FWIW, I've coded https://github.com/castedo/cnest to change to the home directory if PWD is a different device or inode in the container, even if the path exists. Cnest prints out a message to the user in any scenario where the directory is not exactly the same. Here's the line of code sending inode info into the container:
https://github.com/castedo/cnest/blob/d3a333fac1c92356ee406ece8cbc05818fefa20b/bin/cnest#L47
and the code inside the container making use of it:
https://github.com/castedo/cnest/blob/main/cnest/data/cnest-entry
Note it is the combination of inode plus device number that uniquely identifies the true directory identity.

I'm not 100% convinced cnest does the desirable behaviour. But it does seem like it's better to not behave exactly the same in the case of shared vs different directories.