I'm not sure if there is a use case (yet), maybe with parallel builds if the host folder contents ends up with per package staging? https://unix.stackexchange.com/questions/5609/how-do-i-clear-bashs-cache-of-paths-to-executables/218681#218681 We ran into it when we were testing the internal toolchain of buildroot to be relocatable and the "mv" executable was used to rename the host folder. Then we used "mv" again to rename the host folder back. For the first "mv" it used the Buildroot host/bin/mv and then for the second "mv", bash tried to again use the same instead of continuing to traverse to /bin/mv which was in the path and the output of "which mv" at that point in the script.
I don't quite follow what Buildroot can do here, i.e how would we disable this bash caching functionnality from the system-provided bash? I'm not even sure it makes sense for us to do this.
Thinking about it a little more, the actual shell script would need to set 'set +h' but my understanding is the executable hash table (for quick lookup after a commend is executed the first time) is just local to the current script's context. So to cause an issue, you would have to call the same command twice in the same script and move the location of the executable without updating the PATH. That doesn't sound normal. I'll close this bug :-)