Currently, there's no built-in way to have a dynamic number of tabs in ace:tabSet. This was intentional, as we didn't want ace:tabSet to be a UIData, but rather we wanted to have a separate component that would control a set of tabPane components. The idea being that we could mix and match tabs and tabPane components together, much like ice:menuItem and ice:menuItems within an ice:menuBar/ice:menuPopup. Most likely we would not want to force the developers to use Java code to create their ace:tabs children, like how ice:menuItems does though. It should be possible to do it via markup:

<ace:tabSet>
    <ace:tabs value="..." var="myVar">
        <ace:tabPane property="#{myVar.something}>

Right now, the existing solution is to use c:forEach to create a set of ace:tabPane components. There are several problems with using c:forEach in a dynamic way. It's more meant to be configurably static, rather than truly dynamic. By this I mean that when the page first loads, it may use some criteria to dynamically create the components. But from then on, the components should not be added to, removed, or reordered. What happens is that when the list of components grows or shrinks, everything gets shifted, not truly inserted or removed. Input components, bound to ValueExpressions which are derived from the c:forEach var tend to behave incorrectly after the list is modified. As well, c:forEach creates actual components, instead of stamping out the same one, like a UIData does. This has pros and cons. ACE components are mostly resistant to UIData cons, so we're left with having a greater memory footprint with c:forEach, than a UIData.

Something else we'd like to have, is a departure from a dumb javax.faces.model.DataModel base iterative container, which is typically driven by a List. Instead, we'd like to move to a more robust data model, which would inherently support insert, remove, reorder operations. The idea being that these data model operations could then drive dom differencing and client side optimisations. For example, when a tabPane is removed from the tabs container, if the data model remove operation is used by the application, then the client would be able to remove that tabPane without having to re-render or re-transmit any of the other tabPane components.

This more advanced data model could then be built upon to be the basis for the rich data grid, and other iterative containers.