I have encountered an issue with chroot (from Coreutils version 9.0), but I think this email might fall more under the category of "comment" or maybe "question" rather than "bug report", since it's not clear that the observed behavior is unintentional.

I have noticed that chroot will incorrectly report that a command could not be found, when in fact it is a shared library which the command needs that could not be found, while the command itself is actually present.

Example:
say you have the bare minimum dependencies to run 'bash' in some isolated directory:
$ cd ~/my_isolated_env
$ ldd usr/bin/bash
...
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6
$ sudo chroot . /usr/bin/bash -c "echo hello" # successful execution

hello

$ rm ./lib/x86_64-linux-gnu/libc.so.6 # delete shared library that bash needs
$ sudo chroot . /usr/bin/bash -c "echo hello" # unsuccessful execution
chroot: failed to run command '/usr/bin/bash': No such file or directory

Looking at the source code in chroot.c, it doesn't seem impossible to add some logic that makes this error message more accurate (i.e. that a shared library is missing, not the executable itself). Unless this behaviour is well known and intentional (which wouldn't surprise me). In which case, my question would be: why is that? Is this error message not to be considered misleading? Is there some practical reason for not being more specific in this error message?