Svelte 5: next.28 -> next.29 $state array bug

[dm-de]

Describe the bug

something changed between next.28 -> next.29
$state is now defect

I found 2 issues:

1. inserted objects to state array are not the same
   You can see this in example, because delete in setTimeout does not work

2. after insertig some items and removing them all (click on toast to remove),
   here are some issues adding new items... they don't show up or they show up after many clicks.

Reproduction

next.28 working
next.29 not working

LINK

Logs

No response

System Info

System:
    OS: Windows 10 10.0.19045
    CPU: (8) x64 Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz
    Memory: 9.19 GB / 15.96 GB
  Binaries:
    Node: 21.2.0 - C:\Program Files\nodejs\node.EXE
    npm: 10.2.4 - C:\Program Files\nodejs\npm.CMD
  Browsers:
    Edge: Chromium (120.0.2210.121)
    Internet Explorer: 11.0.19041.3636
  npmPackages:
    svelte: ^5.0.0-next.29 => 5.0.0-next.29

Severity

annoyance

[Conduitry]

This sounds like #10118 - is it the same issue?

[dm-de]

You are right - it is the same!

[dm-de]

This bug (issue 1) is not fixed by #10121

[trueadm]

Ah yes, sorry. So many issues I was working on linked back to this one, so I must have tagged this from that.

[dummdidumm]

Mhm I don't think there's anything we can do here. When the object is added to the array, it's proxified, so the comparison is now between a proxy of the item and the item, which returns false.
Side note: I wonder if it's possible to avoid adding a symbol onto the original object and only add that to the proxy instead (so that the original object isn't polluted by the proxy stuff)

[dm-de]

Mhm I don't think there's anything we can do here.

This is then a breaking change!
In the case that it is not changed and stays that way:

1. Please add this to: https://svelte-5-preview.vercel.app/docs/breaking-changes
2. Please add note at https://svelte-5-preview.vercel.app/docs/runes#$state
   That adding non-proxy objects to $state-arrays create new proxy objects

[dummdidumm]

Closing in favor of #11556 which tracks documenting this on the site. #11610 will help surfacing this situation better.