For now Modifier.Node is the new tool and almost not documented in a way of using and migration patterns. on the other hand `composed{}` is discouraged to use. But there are still some cases where `composed{}` is still useful - for example when you create a complex modifier node and you need other modifier nodes that have been migrated already. Most AndroidX modifier nodes are private so you can't access outside androidx package, in that case you need to duplicate or leave it under `composed{}` for now.

Another case where we still need composable{} is accessing private/internal resources in the library. for example, with composed{} I can access composition locals with @composable annotation directly but with modifier node I can't do that and only need to access composition locals, but if the composition local is internal I cannot do that.

Another case is that, because it is not well documented some migrations can be difficult and not worth the effort at all because migration is not straightforward at all.

In every other cases you can use Modifier.Node as a substitute to composed{}