Svelte 5 shared state: stores vs rune modules in a mixed SvelteKit codebase

We are mid-migration from Svelte 4 to Svelte 5 and need to settle one configuration decision before it spreads across the codebase: how shared client state should be declared going forward.

Today we have roughly a dozen Svelte stores (writable and derived) consumed with the $store auto-subscription syntax in components. Svelte 5 runes ($state, $derived) also work in .svelte.js modules, so shared reactive state no longer requires stores. The uncertainty is that the two idioms are not symmetric: $store auto-subscription does not apply inside .svelte.js modules, and interop helpers like fromStore only bridge in one direction. Some state is also consumed inside SvelteKit load results, where serialization strips class instances and non-JSON values.

We want to avoid ending up with two competing reactivity models that new contributors mix arbitrarily, but a full rewrite of every store is a large change we cannot validate quickly.

1. Is there a documented or community-accepted convention for when shared state should stay a store versus move to a runes module during an incremental Svelte 5 migration?
2. What is the recommended pattern for sharing rune-based state with code that still expects store subscriptions, without duplicating the source of truth?
3. Does mixing both models in one component tree have any known performance or update-ordering implications worth testing before we commit?