Is there a performance difference here? Should I always prefer the latter?

fun Modifier.foo() = composed { this.then(FooElement(remember { Foo() })) }
Composable(Modifier.foo())

fun Modifier.foo(foo: Foo) = this.then(FooElement(foo))
Composable(Modifier.foo(remember { Foo() }))

composed is generally bad for performance, yes. The new modifier node APIs are better to use (and also for other reasons)

That's what I thought, thanks for confirming. The API surface here is a bit clunky for the user, as they need to remember a value that the modifier only uses internally. Has there been any thought about how to do this in a cleaner way? (In this case

foo

is a BringIntoViewRequester --I cannot delegate to the node implementation because it's private)

Does the caller of the modifier factory need to be able to call bringIntoView? If so, there’s no way to get around them creating it, since they need access to it. If not, just have your modifier node implement BringIntoViewRequesterNode

Nope, the parent doesn't need access to it. The issue here again is that

BringIntoViewRequesterNode

is currently internal, I'll try to push for that being publicised too

Oh right. It needs a bit of refactoring but I’m pretty sure we can fix that