remember cache returns stale value when mutable key contents change without reference update

The remember function caches a computed value across recompositions as long as the supplied keys remain equal under the runtime's equality check. When a key is a mutable object whose internal state changes but whose reference or hashCode stays identical, the cached value may not refresh, leaving stale data in the UI.

This behavior is a documented limitation across Compose 1.0 through 1.6.x, with no compiler mechanism to flag insufficient keys. The uncertainty lies in determining whether a given key design is safe: specifically, when does structural equality fail to detect meaningful changes, and what alternative patterns—such as keyedRemember with custom equality or derivedStateOf—are appropriate without introducing unnecessary recomposition overhead?

Which equality semantics does the Compose runtime apply to keys passed to remember, and how can developers reliably detect when a mutable key has changed without creating a new reference? Is there a supported way to observe or diagnose stale cache behavior at runtime, or must correctness be guaranteed entirely at design time?