Seeing how LazyColumn seems to fully recompose on item change is there any interest in having each item collect a secondary state in case some day lazycolumn change it's implementation or is the cost of the collectasstate in each items > recomposing the whole lazycolumn from a single collectasstate ?

The regular composable calls skipping is in place here. Recomposing all items doesn’t mean doing a lot of work, we just figure out what items changes and skip the rest. It could help if you extract your items content into a separate composable and just invoke it from inside items { … } block. this will add extra call which can be skipped. no plans to change that

Sorry but I do not understand the "this will add extra call which can be skipped. no plans to change that" .Extracting add a call (I already do that) but I do not understand the skipping part?

There are articles on how recomposition skipping works in Compose. for example: https://www.jetpackcompose.app/articles/donut-hole-skipping-in-jetpack-compose

Yes I've read and understand and even use thing like

@Composable
fun Wrapper(content: @Composable () -> Unit) {
    content()
}

To prevent parent recomposition in some cases when it's costly. The question was more about the whole wording, even if I extract the composable I'll still pass the state to each calls and since the value change all extracted functions will be called again so no real difference here. Imagine having a list of items collected from jetpack paging and the other states would be the connection status to different servers. I can either collect a lastconnectionstatus change at the lazylist level that will trigger recomposition of all the child so doing a full tree checks for actual changes. Or I can have each item collecting the actual state of the server they are related to and so only update themselves and not triggering a whole recomposition. But the collect start a coroutine / stop it and allocate during scrolling, so it was more a theory question about what pattern is best now and in the future? Is tree checking for change more "costly" than the cost of more granularity in updates added by the collect/stop collecting things.

I don’t really think it matters. I doubt connection status changes too often. It could be worth optimizing if you have recompositions happening one each animation frame, but for rare events - it is fine to recompose

Yes it's not that frequent but I've seen a tons of issues with draggable components like bottomsheets and recomposition. So I want to avoid issues with my fastscroll bar. I'll go the global recomposition. And If the draggable issues are back I'll try to build a repro and open an issue.