Please check the BridgeSetup (and any other PostAddToView event listeners that might dynamically add components) and ensure that we are setting the id in a consistent fashion.

It's the same thing as was noted in ICE-5669. If we don't call setId and use something somewhat unique, then we'll get a duplicate id exception.

After some digging through the JSF sources I discovered the reason why we were getting the duplicate ID problem. It turns out that UIViewRoot and any other naming container component will use its own counter for assigning IDs to components (when not assigned programmatically or in the jspx template). The counter value is saved in an associated component state helper.
So, while UIViewRoot would generate IDs based on its counter saved in its state helper and a prefix (UIViewRoot.UNIQUE_ID_PREFIX) same will do a form in the page. The form will have its own counter, assigning IDs to child components with the same prefix (UIViewRoot.UNIQUE_ID_PREFIX ) and potentially with the same values for the counter that UIViewRoot's counter went through.

Right now we are forced to assign IDs to components only when they are appended to a naming container, such as UIForm, and that we already do. Any components added to the tree by using UIViewRoot.addComponentResource method will not need to have an ID assigned because all these components will receive generated IDs based on the UIViewRoot's counter. Some of the components added through UIViewRoot.addComponentResource have their ID assigned because the ID is used by the Javascript code rendered by the component, not to avoid the duplicate ID issue.

It should be possible to create a static page for a test case, for instance 10 forms with prependID = false and several children in each form. The automatically assigned IDs of the form children will collied with the UIViewRoot assigned IDs.

This is a JSF 2.0 bug.