Well, at least, if you have a dangling hard link, the file system itself is broken. And it would not be the normal kind of breakage, at all.
rm will not actually de-allocate a file until all hard links have been rm-ed, in file systems where multiple hard links are allowed. That is, when you first create a file, the directory entry that you see when you ls it is a hard link:
echo "It's a gas." > file.text
# and "file.txt" is a hard link in the current directory.
ln file.text ../linky.text
# and "linky.text" is also a hard link.
rm file.text
# The file is still allocated, still exists, still accessible as ../linky.text
rm ../linky.text
# Now the file system deletes and re-claims the allocation,
# and the file finally ceases to exist.
The OP's problem is not a problem with ls, or with finding the file at all. Nor a problem with bash finding "/usr/local/share/firefox-3.6.28/firefox-bin".
I forget who mentioned it in the parent thread, but, among the other changes being played with in sid, 32 bit emulation is changing drastically, so, even when he gets all the dependencies resolved, he's going to have problems.
If he has some need to use sid, his safest bet (as someone said in the parent thread) to set up a vm, xen or whatever, containing an OS no later than wheezy. (Or the equivalent Mint release.)
If he needs new hardware for that, I'd suggest he requisition it from his company, just to make sure they understand that recalcitrant sysadmins are costing them money. And I'd recommend he points his management to the parent thread, so that management is aware that, not only is using the ancient VPN non-solution costing him money in terms of service OT, but leaving them vulnerable in the very place where they are trying to establish security.