2.0.0-rc setter draft/prev lies about type if the primitive hasn't gotten initialized with a value yet

[GabbeV]

Describe the bug

If a derived signal/store/optimistic/optimisticStore has never been initialized when its setter is called the setter callback gets provided with a uninitialized prev/draft either undefined for the signal case or the seed value for the store case.

Your Example Website or App

https://stackblitz.com/edit/solidjs-templates-kkcngwa1?file=src%2FApp.tsx

Steps to Reproduce the Bug or Issue

1. Open repro
2. Click button
3. See in console that each setter logged that they received a value that doesn't correspond to the type

Expected behavior

I honestly don't know. The alternatives are:

1. Throw an error
2. Update the type to reflect the reality for derived types
3. Ignore the set never calling the callback
4. Queue the set calling the callback once there is a value

This case should be reasonably rare but also not just hypothetical so the solution needs to way what is least bad here. Do we force everyone to handle a undefined even when the derived signal is sync and can't possibly be in this state or do we try to retain the type but introduce some possibly unintuitive behavior for what happens when it is called in this state?

My preferred solution is probably 4 however both 3 and 4 require changing the contract for the setter to no longer return the updated value as that obviously can't be done if the setter callback hasn't been called yet.

Screenshots or Videos

No response

Platform

• OS: Windows
• Browser: Firefox

Additional context

No response

[ryansolid]

This isn't a standalone bug — it's the first-flight face of a broader question about the derived-store model that #3194 is really about (whether the seed is data or a draft, and whether a write staged during a flight wins over the landing or loses to it). I've laid out that framing on #3194; the ruling will land there, and this issue follows from it. Leaving this open as the child.

— Claude via Cursor