That's better. Screenshot.

Once I did the test with one of my own skins, which can accommodate an absolute or relative URL for the favicon, with any file name, and without the byzantine variants, I knew what the underlying story must be.

One last little tidbit to pass along....

RobM, in helping to hunt down this problem, discovered that Safari caches its favicons in a way that isn't fixed by doing a hard refresh, or even by deleting all of the browser data. So, when you view a page that already had a favicon, but now has a new one, you'll keep seeing the old one pretty much forever, unless you manually wipe out the contents of:

/Users/YourName/Library/Safari/Favicon Cache

Great!
The correct behaviour would probably be to use our default favicon if there is none at the requested location of the customer storage, but to never override it if there is one. But that isn't a 10 minute fix (including deployment).
The behaviour before todays fix was just broken.

With one exception, not directly related to jAlbum-produced albums. If you have your own hosting (i.e., not jalbum.net), and you want to have a single, fallback favicon that everything on your domain uses, without needing to include it on every page, you need to plant favicon.ico at the root of your domain. That's what browsers will look for, as long as there's nothing more specific on the page in question. The browsers won't automatically look for any other name.

I can always blame a former employee (which is actually true in this case. I looked it up).