I tested this using IE 9 and using the Developer console to switch the browser modes (IE 9, 8, 7) as well as the the document modes (standards, quirks). I could only reproduce the problem in the test case when the document mode was set to "Quirks". Then I would see that additional ViewState parameters were being included in the form submission.
To confirm, I used the debugger to show that the following line in jsf.js doUpdate():
var field = stateForm.elements["javax.faces.ViewState"];
is returning the field as "undefined" when running IE in Quirks mode. Not really sure why this is. Looking at the form, it appears the element array is there. And checking for the existence of other form elements using the exact same syntax works. For example:
var buttonOne = stateForm.elements["button1"];
returns the appropriate input element. So it must not like something about "javax.faces.ViewState". As Mircea noted, perhaps the dots where throwing it off but I tried a stand-alone script that simply iterated through a form and it was able to find the hidden input text name "javax.faces.ViewState" so there must be more variables involved.
In any event, when it can't find a ViewState it goes ahead and appends a new one - which is why we see the multiple ViewStates being accumulating with each submission. The patch avoids this by checking to see if the ViewState is found and, if not, before adding a new one, tries an alternate approach of iterating through and comparing the each form.element.name with the incoming ViewState value.
Modified one remaining instance in our bridge were the javax.faces.ViewState input element was looked up by name instead of using the utility function lookupViewStateElement(). The function was introduced when we discovered that IE9 fails to look up the elements by complex names (such when the name contains dots).