To remove a red herring here, the special characters in the values don't change the outcome. Here is a simpler case, with the last selection changing the text to show that it was able to select the right element: http://jsfiddle.net/zksm1o5q/5/

Here's a bare DOM example without jQuery that exhibits the same problem: http://jsfiddle.net/15ytbys8/

This is a browser bug, but perhaps we should work around it in a propHook that sets all other option elements' selected values to false?

Does that fix the problem? Is it only a bug with options that exist in the select already, or would we also need to guard against ones appended from elsewhere?

This seems to work on Edge so it's only IE11 (and older IEs) affected.

In any event it seems like that might really be a performance killer, especially on selects with a lot of options. I guess it could be limited by a feature detect to only IE and only when changing the selected property, but silently trying to cure it might lead to a real performance trap. I'm also wondering if properties like readonly or disabled misbehave the same way?

What about setting selectedIndex on the select element instead of setting all the selected properties?

That wouldn't be a big perf hit – or code size hit – and it seems to work: http://jsfiddle.net/timmywil/15ytbys8/1/.

I don't think disabled or readonly would have the same problem because multiple options can be disabled and readonly.

Yeah if that works it sounds pretty good. So if we're setting selected on an option and it's already in a select that is not multiple, set the selectedIndex property. #youmightnotneedjquery

This is a non-breaking change; should we backport it to 1.12.2 & 2.2.2?