Svelte 5: Modifying unbound state in a child component does not error about svelte HOT 2 CLOSED

I lean towards marking this as "works as designed". We can't know the intention of someone putting state from one place into another. We err on the side of caution to not produce (much more annoying/bad) false positives which, depending on what you're doing, may result in a false negative in some cases.
The underlying system assumes that assinging state to another state means that the ownership is widened. Changing this heuristic would come with signifant drawbacks and I'm not sure we could keep the current validation strategy in that case. Therefore closing.

from svelte.

I'm fine with just remembering not to do it, but...

I'm pretty sure that "duplicating" state like this, be it directly mutable (from $state,) derived, bound or unbound, is always a mistake, or at least an anti-pattern. It can't be good to have two mutable states pointing to two states that can directly mutate the same / overlapping / nested prox(ies). And there's really no use case. If a component needs extra state to do its job, surely the pattern should be:

• init the extra state from props (making sure to remove reactivity)
• update the bound prop from $effect or a function.

from svelte.