I think current design of Modifier.Node system comes with a biggest problem: closed for further extension. Unlike Modifier system, where one can freely compose one or more Modifiers, almost all the underlying Modifier.Nodes emitted by these Modifiers are considered as "leaves" and can't be used to compose a custom Modifier.Node. This is especially true for Modifiers which take in lambdas like

offset

,

onFocusChanged

,

pointerInput

, where users need to write those logic over and over again.

You can compose modes via delegation (DelegatingNode), as long as the node types you want to delegate to are exposed. There are major improvements to the delegation system coming up too.

Like the following modifier I have in my project can't migrate to Modifier.Node without copy-paste:

fun Modifier.themePadding(
    size: ThemePaddingSize
): Modifier = composed {
    val themePadding = LocalThemePadding.current
    padding(themePadding[size])
}

enum class ThemePaddingSize { /* ... */ }

I would have to use

padding

like the following if I want to get rid of `composed`:

modifier = Modifier.padding(LocalThemePadding.current[/* ... */])

where I have to add

Local...

on each invocation. I like the fact that DelegatingNode and CompositionLocalConsumerModifierNode is coming into view, but as you said, if the corresponding Modifier.Node type is not public, like

padding

, there's nothing you can't do 😥