ComposeView‑AndroidView integration: Managing composable visibility to avoid accidental public APIs

Goal: Ensure that composables used in integration points such as AndroidView or ComposeView remain encapsulated within their defining module and are not unintentionally exposed as public APIs.

Constraints: By default a @Composable function is public unless marked private or internal; lambdas supplied to AndroidView can capture and expose composables to the hosted View; ComposeView.getContent() returns the internal Composition, allowing external code to inspect or modify the UI tree.

Uncertainty: The Compose team has discussed changing the default visibility of @Composable functions to internal or introducing an annotation like @ComposableInternal to discourage accidental public exposure, but no decision has been finalized in the latest stable release.

Should @Composable functions default to internal visibility? Would an @ComposableInternal annotation provide a clear opt‑in mechanism for internal APIs? How can teams enforce visibility boundaries across the Compose‑View integration without breaking existing consumers?