ListRenderer

List -- a scrollable run of children, usually generated from a bound array.

Every List in the specification's corpus binds a template rather than naming ids, and the adapter layer has already expanded it by the time this runs: rememberAllChildren returns one entry per item, each carrying the collection scope its relative paths resolve against. So this renderer is a container and nothing more, and templating is not a thing it has to know about.

A scrolling Column/Row, not a LazyColumn/LazyRow, and the reason is measurement. The lazy lists are SubcomposeLayouts: they cannot answer intrinsic measurement queries, and they fill the main axis they are given rather than wrapping their content. Either one breaks a list nested in ordinary content -- a LazyColumn inside a Column claims the whole remaining height and pushes its siblings off the surface, which is what the corpus's dashboards would do. A scrolling Column wraps when its content fits and scrolls when it does not, which is the behaviour the guide is describing, and it stays measurable by the Row/Column above it. See the note on verticalAlignment in Layout.kt, which anticipated exactly this.

What that trades away is virtualisation: every item composes, including the ones off screen. The instance budget the adapter layer divides among children is what bounds that, rather than the viewport -- an adversarial array cannot make this compose more instances than the surface was allowed, it just composes the ones it was allowed all at once.

No margin and no padding, which is §3's rule for the structural containers: Row, Column and List contribute zero spacing so that nesting them does not multiply it. The items carry their own.

align: stretch, the catalog's default, is drawn as start here, though Row and Column now stretch. Compose has no stretching Alignment, and a fillMax* taken inside a scrolling container measures against what the parent offered rather than against this list's own content; Layout.kt stretches by measuring each child against a line it learns first, and this list is a plain Column that cannot. So a leaf item keeps its natural width instead of squaring up to the widest. A Column item does fill the list's width, as it would a block's, and so does one inside a Card item, which gives its content no width of its own -- a list of cards around columns is as even as the catalog's default asks.