In my experience window.history.start's pushState option should be called something like autoUpdateDeepLink as pushState is a loaded word specific to compatible browsers and the Backbone behavior seems to not only enforce html5 push state if this option is passed but also convert push state urls into hash urls for browsers that don't support push state. I've seen examples online where people hook up this flag to Modernizr.history so it gets set to false for IE which makes sense with the current variable name but not the behavior I am seeing.

In that context of setting pushState to true for IE to get the hash url to auto update I am finding everything works great except if you pass querystring variables along with you hash URL Ex:

http://test.url.net/#portfolio/PyUP6R9 works fine
http://local.pathbrite.net/?asdf=sdfsdf#portfolio/PyUP6R9 redirects to http://local.pathbrite.net/?asdf=sdfsdf#.

I tracked this strange behavior to:
var atRoot = (loc.pathname == this.options.root) && !loc.search;
in the Backbone.history.start method. Its set to always expect the web app is not at site root if there is a querystring present which does not make any sense to me. In my context a querystring for analytics is present which should not effect Backbone's atRoot logic. My solution was to comment out the && !loc.search.

TLDR: It seems Backbone.history.start only considers you at web app root if you don't have a querystring present. This is causing my IE urls with querystring+hash to lose the hash value.