TabsRenderer

Tabs -- one child at a time, chosen by a strip of headers.

The selected index lives here and nowhere else. The guide says so in as many words -- "maintain a local selectedIndex state (defaulting to 0)" -- and the catalog gives a Tabs no property to bind it to, so this is one of the two components in the catalog whose state is the renderer's rather than the data model's (ModalRenderer is the other). Which tab is open therefore does not survive the component being replaced, and the agent cannot read it: a payload that needs the selection to reach the agent has to build the strip out of Buttons instead.

Only the selected child is drawn, which is what the guide asks for and is also what keeps a ten-tab surface from composing ten subtrees to show one. The hidden children are not composed at all, so their state does not survive a tab switch either -- text typed into a field on one tab and returned to is gone. That is the guide's behaviour rather than an oversight; a renderer keeping every tab composed would be the trade in the other direction.

The guide and the catalog disagree about the shape, and the catalog wins. The guide describes "a horizontal row of interactive tab headers for the titles" with the child corresponding by index, as if a Tabs carried two parallel arrays; catalog.json has a single tabs array of {title, child} objects, which is what every example in the corpus sends and what the child resolver already walks. Pairing by index inside one object cannot go out of step the way two arrays of different lengths can, so nothing here has to decide what a title with no child means.

weight is the only other property, and a row or a column reads it off this component rather than this renderer reading it -- see Layout.kt.