Old structure was even worse because there is 31998 limit sub-directories per one directory in ext2,3 filesystem and there is no limit (or it is very high) for number of files per directory. Now you are talking about limits of the software you are using for browsing, but not system limit.

In the future we will consider structure like this /a/b/c/d/abcd4543564.jpg, it will solve both problems, yours (with software you are using) and filesystem limits.

the sub-directory structure was/is relevant see more to a 32bit OS running a specific build. ext3 still retains the 32000 subdirectory limitation, but its not the subdirectory structure, its an issue with creating links:

A safe way to try it out; create a relatively small file (like 20MiB), format it with ext3, mount it, and see how many directories you manage to create ;)
I did try on a VM, and I only managed to produce 5123 subdirectories in a/ before it said: mkdir: cannot create directory `xxxxx': No space left on devicekblft is correct; the limit is on a per-subdirectory basis. You can have more than 32,000 subdirectories in a filesystem, just not in a single subdirectory. I did some tests on this recently.
That seems to contradict with the results I've got from geirha's code? Any ideas why?
I expect ext4fs will be more reliable in 6-12 months. Beyond that, Btrfs is likely to become the "top dog" among Linux filesystems. At the moment, though, Btrfs is even newer than ext4fs, and I wouldn't trust Btrfs with valuable data.
At the moment I think "ext3" still works for me. Although data on my development server isn't really that valueable, I like my machine to be stable. So if I don't need to change to another (less reliable) filesystem I prefer not to change. Thanks for the information anyway.