This could potentially be addressed by discontinuing reliance on large preconfigured configuration objects to be passed into the GoogleMap() composable. Instead, configuration lambdas/blocks could be used, e.g.:

val propertiesConfig: MapPropertiesScope.() -> Unit = {
    // API consumer might care only about setting a specific map type
    this.mapType = TERRAIN
}

GoogleMap(
    mapPropertiesConfig = propertiesConfig
) {}

These configuration lambdas can be readily executed and observed for changes during composition.

In fact, to do this cleanly, it may be necessary to introduce MapConfigurationState that encapsulates all mentioned configuration options, including camera, location source, inside padding. If a user provides a new MapConfigurationState object then the GoogleMap & MapView would need to be recreated, unless there is a reliable way to reset the map configuration to defaults.

The reason for needing this kind of thing is to keep the Compose API properly declarative. The 2 possible properly declarative approaches I see for this are MapConfigurationState or exhaustively setting all options.

Alternatively the Map could also be configured from inside the subcomposition/content block via side effects. The inherent constraint of this approach is performance: initial composition of the potentially complex subcomposition needs to be complete before configuration actions can be performed. Arguably, initial map loading should already be happening in parallel during this time. So I think the subcomposition needs to stay reserved for only configuring the map contents, not configuring the map itself.