First of all, thanks to you guys who answered! =)
I've now done a lot more research and I believe I'm satisfied with my implementation. Here are the results of my research.
First of all, my finished Hash library. It's a stand-alone library with no dependencies. It has two functions: Hash.init(callback, iframe) and Hash.go(newHash). The callback function is called whenever the hash changes with the new hash as its first argument, and as its second argument a flag indicating whether the callback is called due to initial state (true) or an actual change to the hash (false).
Hash.js (MIT license)
I also made a jQuery plugin for making it easier to use. Adds a global hashchange event as well. See example in source code for how to use it.
jquery.hash.js (MIT license)
To see them in use, go to my JavaScript "realm" page:
Blixt's JavaScript realm
Internet Explorer 8
Smooooth cruisin'! Just smack on one o' them onhashchange events to the window object (using attachEvent) and get the location.hash value in the event handler.
It doesn't matter if the user clicks a link with a hash, or if you set the hash programmatically; history is kept perfectly.
Chrome, Firefox, Safari 3+, Opera 8+
Smooth cruisin'! Just poll for changes to the location.hash property using setInterval and a function.
History works perfectly. For Opera, I set history.navigationMode to 'compatible'. To be honest, I'm not sure what it does, I did it on recommendation from a comment in the YUI code.
Note: Opera needs some additional testing, but it has worked fine for me so far.
Surprise quirk bonus! (Can it be?!) It turns out that Firefox (only confirmed in 3.5+) decodes the location.hash property, so this can trigger a hashchange event twice (first for the encoded version then for the unencoded version.) There is a new version of my Hash.js library that takes this into account by using the location.href property instead (changes provided by Aaron Ogle.)
Internet Explorer 6, 7
Now it gets nastier. The navigation history in older Internet Explorer versions ignore hash changes. To work around this, the commonly accepted solution is to create an iframe and set its content to the new hash. This creates a new entry in the navigation history. When the user goes back, this changes the content of the iframe to its previous content. By detecting the change of content, you can get it and set it as the active hash.
Checking for changes to the location.hash property is still needed to manual changes to the current address. Beware of the quirks I've mentioned below, though.
While this solution seems to be the best one out there, it's still not perfect in Internet Explorer 6, which is a bit quirky about the back/forward buttons. Internet Explorer 7 works fine, though.
Surprise quirk bonus #1! In Internet Explorer 6, whenever there's a question mark in the hash, this gets extracted and put in the location.search property! It is removed from the location.hash property. If there is a real query string, however, location.search will contain that one instead, and you'll only be able to get the whole true hash by parsing the location.href property.
Surprise quirk bonus #2! If the location.search property is set, any subsequent # characters will be removed from the location.href (and location.hash) property. In Internet Explorer 6 this means that whenever there's a question mark in the path or the hash, you'll experience this quirk. In Internet Explorer 7, this quirk only occurs when there's a question mark in the path. Don't you just love the consistency in Internet Explorer?
Surprise quirk bonus #3! If another element on the page has the same id as the value of a hash, that hash will totally mess up the history. So rule of thumb is to avoid hashes with the same id as any elements on the page. If the hashes are generated dynamically and may collide with ids, consider using a prefix/suffix.
Other browsers
Unless you've got an out-of-the-ordinary user base, you won't need to support more browsers. The browsers not listed above are in the <1% usage category.
