We traced a real-world site issue [1] to an ambiguity in the HTML5 parsing spec regarding the magical "form owner". For a refresher, the HTML5 spec says:

4.10.18 >

| When a form-associated element's ancestor chain changes, e.g. because
| it or one of its ancestors was inserted or removed from a Document, 
| then the user agent must reset the form owner of that element. The 
| HTML parser overrides this requirement when inserting form controls.

...so, DOM operations that move elements around should reset the form owner. Cool. So, then what's the caveot with the HTML parser? It's here:

8.2.5.1 >

| If an element created by the insert an HTML element algorithm is a 
| form-associated element, and the form element pointer is not null, 
| and the newly created element doesn't have a form attribute, the 
| user agent must associate the newly created element with the form 
| element pointed to by the form element pointer when the element is 
| inserted, instead of running the reset the form owner algorithm.

...OK. This only identifies the "insert an HTML element algorithm" as meeting this requirement. This is what IE10 implemented. However, it turns out that the above exception is too narrow. 

4.10.18 should add that any algorithm employed by the HTML5 parser (such as the Adoption Agency algorithm), also overrides this behavior. Suggested text for the note:

"Note: The HTML parser overrides this requirement when inserting *or re-arranging* form controls, such as in the Adoption Agency algorithm."

The modified note above appears to match the behavior we are seeing currently in Firefox and Chrome, and is compatible with existing web content.

[1] http://www.elightbulbs.com/shopping_cart_process.cfm?action=pre_checkout