Is there any concept in mind of how the composable should be decoupled or how big should/could be views/pages/screens with nested composable elements? Another question is, what is the best way to pass or get an instance of the ViewModel inside compose element?

Let me preface this by saying that much of this boils down to judgement calls on your part, because you are the one who will need to maintain your own code. That said, I can give general advice based on what I've seen people do and what tends to work/fail in my experience. As a general rule of thumb, keep your widgets as decoupled as possible. Passing in data to show and callbacks to notify parents is exactly the correct design, follow that pattern to the maximal extent possible. It will feel unfamiliar, so push past your discomfort, and your future self will thank you for it. Widgets can (and should) have their own logic, and can introduce/expose their own classes and data model types. For example, a

DatePicker

or

CreditCardEntryForm

or

AddressForm

could all have very sophisticated validation logic. If you were implementing GoogleDocs, you might have a

GoogleDocTextEditor

widget that took in a mutable

RichTextDoc

data structure describing the document. But the logic of these widgets should be self-contained to the widget's specific concerns, and not explicitly depend on the app as a whole. If your widget has a reference to your

Activity

, you're almost certainly doing it wrong. Compose widgets are certainly expected to replace Fragments in general usage, but I'd suggest using a mental model that is closer to custom views. Fragments were a very leaky abstraction that wasn't conducive to good encapsulation. Instead, you want to build reusable chunks that feel like something you could embed into another app. At some point you will intentionally break this rule, but if you feel the need to ask the question, then you're probably not yet ready to break the rule.