I think I am observing that even though @Composables will rerun when their parameters change, if a closure for a pointerInput function closes over a simple value, prepared for a sub composable in that scope, that pointerInput may not be recomposed, resulting in the closure referencing a stale/old value. Would that be correct?

Hard to tell from your abstract description, but that sounds fishy. Do you have a minimal example which demonstrates the issue?

Something like this: ParentComposable var selections by remember mutableStateOf(Set<Int>) SubComposable(selections = selections) mod = Modifier.pointerInput { doThingsWith(selections) } SubSubComposable(modifier = mod) I think that captures it. What I see is that under some cases, after selections has been changed, the doThingsWith() arg is an older version of selections.

Yes, that is expected.

pointerInput

requires passing a

key

that controls when the

block

is cancelled and restarted. You have a couple options for how to handle that, depending on the behavior you want. The doc of

pointerInput

goes into more detail: https://developer.android.com/reference/kotlin/androidx/compose/ui/input/pointer/package-summary#(androidx.compose.ui.Mod[…]utines.SuspendFunction1)

I wonder if there is a learning style called "learning by need" 😄 That totally makes sense. I have read in "random access" mode ore than once. But the whole "key" thing was always kinda "hmmm...". And so many of the examples you find just use Unit as the key, so you do that. Simply adding the key to pointerInput(selections) { } made things work. And now that I need to understand this, it suddenly seems totally obvious. Thank you