This issue was due to a change in how the tabset sets the disabled state for a tab:
Originally, the tab rendered a style class on a particular node to indicate it is disabled, and during the YUI tabset component initialization, the appropriate tab was disabled in the JS model of the tabset. However enabling the tab rendered the tab, but not the tabset, which is responsible (in the YUI JS) for managing 'selectability', so the tab remained unselectable.
To fix this, tabs were no longer initialized as disabled, they are rendered alike, and the ACE tabset JS has an array indicating the disabled tabs, and at ACE tabset init, we disable the tabs via the available YUI tabset API. However, because the ACE tabset init follows that of the YUI tabset, the YUI tabset has already initialized itself, which includes selecting the first non-disabled tab. If possible the code to process the disabled state included with the ACE tabset config should run before the YUI tabset init- adding the disabled style class to appropriate tabs, allowing the YUI component to init correctly.
Ok, the issue is that a customer expressed interest in the tabSet defaulting the initial selectedIndex to the first enabled tabPane's index, as opposed to the default value of zero. It would be possible to interpret a negative selectedIndex in this way, and set it to the initial enabled index. There is the question of, if the enabled values change, whether the selectedIndex should be recalculated. It would be less feasible to know to do this, unless the selectedIndex was again reverted to a negative value.
It seems, considering the additional complexity and regression risk, that an application could instead simply specify the desired selectedIndex themselves quite easily.