Svelte 5 legacy mode: combining svelte:options immutable with accessors and prop setters

Context

I'm maintaining a Svelte component library that still uses the legacy compiler options (pre-runes style, Svelte 4 / Svelte 5 compatibility mode). Several components declare <svelte:options immutable={true} accessors={true} /> so parent code can set props directly through component instances.

The uncertainty

The immutable option tells the compiler that props and state are never mutated in place, so it can skip dirty-checking work. The accessors option generates getters and setters for each prop. What I can't find documented is the interaction: when an external caller assigns through a generated prop setter on an immutable component, does that assignment reliably invalidate dependents — including reactive statements that read nested properties of that prop?

My concern is that immutable assumes referential changes signal updates, but the setter path may bypass or duplicate the invalidation logic, and nested reads could silently go stale in ways that differ between dev and production builds.

Questions

• Is the behavior of prop setters under immutable={true} + accessors={true} defined anywhere, or is it intentionally unspecified?
• Does the answer differ between Svelte 4 and Svelte 5 legacy mode?
• What is a reliable way to verify invalidation behavior in a component test without relying on implementation details of the generated code?