Potential footfun: Updated streams do not show their value until the next tick.

[JAForbes]

I'm hesitant to label it a bug, but I think before v1 this would need to be fixed to prevent many other issues being reported by users.

@pygy suggested that S's subclock implementation may solve this. So we should definitely look into that.

I think if that doesn't pan out, we could maintain a stack of stream contexts (in our fork) and return the latest value when we can detect we're in an S context.

[pygy]

@JAForbes this is a deliberate S.js choice:

A Clear, Consistent Timeline - S apps advance through a series of discrete "ticks." In each tick, all signals are guaranteed to return up-to-date values, and state is immutable until the tick completes. This greatly simplifies the often difficult task of reasoning about how change flows through a reactive app.

Batched Updates - Multiple data signals can be changed in a single tick (aka "transactions").

We can revisit the timing model, but we must understand the systemic consequences of doing so (and I don't, right now).

Note that S.freeze() (the transaction helper) is broken by the monkeypatch as I type this.