Just as an fyi, it seems it's IE actually comparing the underlying html inside the <a> tag to see if that identically matches the href url. Even if the rendered text is the same, but the html is different (for instance the / character replaced with an html entity, or some part of the link text is wrapped in a <span> or <b>, etc), IE will not mess with things. So the proper check to see if IE needs to be quirk-fixed is something like: $(this).html()===$(this).attr("href")

Two thoughts on a workaround:

1. Prevent IE from doing its dirty work by first breaking the exactness between the two properties. You could insert/append some invisible html entity (like <wbr> for instance?) to the html of the link first, then change the href, then remove the shim. That should fix the quirk, but also prevent any layout re-rendering "flashes" or other ugliness to users, giving a better user experience it would seem.

2. Or, you could let IE do its work and then clean it up. Thankfully IE lets you change the html right back after it messes with things. So, you can first capture/save the innerHTML of the link, then change its href, then change it's html right back. For good measure, you also temporarily set visibility:hidden on it while the flip occurs, to cut down on layout re-rendering "flashes". Maybe display:none is better, but then it moves surrounding content temporarily in to the real-estate taken up by the original link, causing the undesired layout-rerendering.

Follow up: I tried method #1 on my site and it works just great. Here's the code I used:

$(alink).html($(alink).html()+"<wbr>");
$(alink).attr({href:val});
$(alink).html($(alink).html().replace(/<wbr>$/i,""));

Should the core really try to fix this? Seems like such an edge case with a very simple workaround. Not even sure how this would fit into $.support.

I think this is better just documented.