The problem initially occurred when logic triggered while clicking on ice:treeNode which cannot be replaced with an h:commandButton so I don't understand how that work around will correct this issue.

What happens was the user clicks on this tree node which brings up either one or both richdatagrids based on some conditions. Intermittently this duplicate column issue would appear when that occurs. I don't know if the test case has been simplified too much which removes the treeNode but that is an integral part of the application and cannot be replaced with a button.

Upon investigation I noticed that many autogenerated jsf component ids were changing at the rerendering of the new data grid. I've added more explicitly set dynamic id's to the sub components of the rich data grid to avoid this, although the update issue is still happening.

The column data on the server appears to be correct. On clicking the 'Show New' button to render the new table, the columns of the existing table are resolved to be the following (column name, visibility state):

columns [ id:true, firstName:true, lastName:true, dept:true, section:false, company:false ]

I've ruled out partial update anomalies. The DOM updates are being reconstructed properly, although the DOM updates themselves are being generated incorrectly. eg: one of the updates occurring on the rerendering of the new table is the following column data:

<div class="icePnlGrp richDatGrdCol"
id="iceForm:richDataGridNew_subview:richDataGridNew:1:id_text_ctr"
oncontextmenu="Ice.Menu.contextMenuPopup(event,
'iceForm:richDataGridNew_subview:richDataGridNew:1:createRowMenu_sub',
'iceForm:richDataGridNew_subview:richDataGridNew:1:id_text_ctr');return
false;"
style="width:;">
<span class="iceOutTxt"
id="iceForm:richDataGridNew_subview:richDataGridNew:1:id_text_ro"
title="Johnson">Johnson</span>
</div>

Looking at the update, this is the last name cell value of 'Johnson'. Although the id's are incorrect. The id 'iceForm:richDataGridNew_subview:richDataGridNew:1:id_text_ro' should belong to the cell of the second row first column, named 'id', a text column, in the read only state. So, it appears that the outputText for the 'id' column, has the value set for the last name column.

So, since this doesn't appear to be a partial update or DOM diff issue, it points to a state saving issue on the component level. Further investigation is required. An interim workaround that could be provided very quickly is creating a 2nd separate richDataGrid component, with a different set of internally rendering id's, which may, perhaps, shield the components from any variable scoping issues.

Still looking for a solution to this, although the issue still appears to be a JSTL scoping and possibly a JSF component id issue. One current simple workaround is to call FacesContext.getCurrentInstance().getViewRoot().getChildren().clear(); before rendering the second table:

class TestBeanNew{
...
public void resetList(ActionEvent event)

...
}

Clearing the JSF component children of the panelGroup containing the new data grid In the test case should also be a workaround.

All of the workarounds suggested either don't satisfy the requirements or they don't work. I see the latest EE release was added to the end of this but the issue is still open. Does that mean that code changes were actually made in 3.0.0.GA_P01 and it works or does that mean just try one of the workarounds that doesn't work?

Retested on ICEfaces EE 3 rev 33253 with or without the workaround. Note that this build is now using Mojarra 2.1.17, which includes state saving bug fixes that have may have been the root issue here.