That problem turned out to be that the view state key was changing in the form. It turns out that ICEfaces updates can only be applied to an element with an id so the code ascends the hierarchy until it finds the first element with an id (which is the form) and inserts that into the update queue. This causes all the children of the form to be sent.
The solution to this problem was to encase the <input> tag containing the View state key in a div tag that has an id. I don't want to monkey with the results of the JSF code that is generating the <input> tag.
Moving on to the next problem, trying the code in the auction monitor example application. Again the application has some form of problem where the body tag is modified and the entire page is resent. This problem was traced back to the UIXHtmlComponent representing the DIV tags for "chat_content" and "auction_content". This component is not saving its state properly, and as a result, the rendered ID wasn't being preserved. This was causing the DOM id's in the old and new DOM to be different resulting in the parent node (body) being sent. Note that the ID of the component itself is correctly restored, but not the rendered ID.
There may be some components that don't support saveState and restoreState at all, plus perhaps some that don't support the methods properly. The following packages are suspect in that they exist, but a search doesn't reveal any saveState or restoreState methods. It well may be that they don't need to support these methods, etc.
component\src\com\icesoft\faces\component\
drag-drop
gmap
input rich text
menu-bar
menu-popup
panel divider
panel tool tip
output style
however output style is definitely a problem, as the DOM (in auction Monitor application) before state saving has 7 elements, and the DOM after restoration has 5 elements with the 2 missing elements being links to style files.
May need to get some component support for this operation.
Progress on this issue is at about 80-90%. State is being saved in the session, the key to restoring state is being written to the client, and the key is found and identified if passed back in a request and can be used to restore state. State is apparently restored. Apparently is the term used because it's not completely obvious if it is restored or not, none of our applications seem to require it.
At this stage one remaining issue is that when the form is restored, the id changes, and something causes all the forms children to be rendered. Currently these aren't being diff'd out, with the result that the update contains all the children, meaning that if you are typing something in an input text, it's erased. There have been a couple of changes that could be responsible for this changed behaviour so I'm still working on that.