Will Henderson

I've written a preliminary patch to resolve this (see https://github.com/WHenderson/svelte/tree/develop/stores-diamond-dependency) and in doing so I've noticed the test case "derived dependency does not update and shared ancestor updates". It is...

FYI, this is what I believe the correct behaviour should be: ```mermaid sequenceDiagram autonumber participant input participant a participant b participant c participant log note right of a: a ==...

> 1. ...In the example, when store A updates, store E will be invalidated twice Hi @mnrx , the stores aren't keeping a simple boolean invalidation state. They are keeping...

> Looking again at your patch implementation, I think the invalidation initiated by derived stores may be unnecessary but it would require more logic to disable that step for derived...

Correction > derived dependency does not update and shared ancestor updates This is actually failing because I tried to skip part of my original solution (revalidation). Guess I'll bring that...

> That invalidation is necessary, yes, but the following round of invalidation initiated by the derived store setting its new value is not. It would require more logic in set...

> "does not freeze when depending on an asynchronous store" **svelte 4** `[3, 2, 5, 8, 11, 8]` at the point where `length.set` is being called, `lengths_derivative` erroneously believes all...

> The bit that would break with more than 32 stores is the `pending` bitmap, which is only used to ensure that the "diamond dependency" problem doesn't cause undesired updates....

I can see utility with this proposal. I would suggest some discussion around the callback signature though: With the proposed signature `(values, set, update, changed)`, users are (almost1) forced to...

> So, you're suggesting that `const` props could be set externally. What happens when `answer` changes value? > > ``` > > answer += 1}>Increment > ``` My suggestion would...