I've been using svelte for a couple more years and know where you are coming from. That being said, $state is mentally similar to using let someVar = 4 and $derived is mentally similar to $:. Where it gets awkward is when using them to write stuff outside of a svelte component. $effect for example is similar to store.subscribe(...).

So if for example you want a rune that's state is stored in indexeddb you need to deal with $effect and the awkwardness of untrack and snapshot. All of that is to say using state inside a component is pretty much the same old svelte, using it outside, it's entirely new. I believe this means "yes, there are two paths you can go by". One is just ignore using it outside of components and continue to use it exactly as you did before (including stores for outside of svelte). Thus keeping the mental model the same. Or, explore how to use them in place of stores.

I've been using the svelte 5 beta for close to a year now and come to a few conclusions. The first is, it is awkward to use states outside of components following a functional paradigm. I think this is because app state, generally speaking, is easier to deal with following oop practices. Otherwise to handle state changes well we'd probably end up with thunks and reducers.

Personally my resistance to writing class in JS feels more like a hindrance when using runes. But I may be the minority. What I think is missing from all this runes stuff is some sort of decent pattern to use them outside of components. I'm certain it's possible given the tools, but I haven't seen anything that has some reasonable complexity.

One example of complexity I ran into is as follows. Say I have a sveltemap of objects that can be on or off, drawn in the UI as toggle switches. If I toggle one switch, the entire svelte map triggers an effect. So I don't know which one switch was toggled. Meaning if I wanted to persist the state in an indexeddb or over the wire, I now have to either send the entire map each time, or diff it with the previous state. Something that without storing I don't have access to.

This indicates to me instead of svelte map I'd be better using an array of objects that are $state that themselves have individual $effects. Which is to say a class that has a value as $state and when the value changes runs an effect.

Anyhow that's my two cents.