Fetching data will definitely be one of the more interesting use cases for the func/proc separation. However, I've got a pattern I've already had success with in MobX which should translate here:

- loading state, response value, and any error are all observable state (wrapped up in a class)

- at creation time you pass a lambda that just generates a promise; this function is set to automatically re-run whenever its dependencies change (this will need to be slightly different for Bagel because promises run eagerly; I plan on somehow expressing a "lazy request" or "request spec" as a pure value that can be generated in a pure context and then requested later in a procedural context)

I've seen Immer, it's a very cool idea. Right now I'm planning to stick with raw values even for immutable code, though I'm definitely interested in optimizing over that if I can do so transparently

> maybe with a language construct that allows mutability only within a certain scope?

I've already got a language construct that allows mutability only within a certain scope ;)

As for priorities/focus, I would say the order is:

1) Web GUIs

2) Web Servers

3) Games (probably web-based)

4) Everything else (scripts, etc)

I have interest in supporting all of these, and I don't think anything I'm doing will be prohibitive of any of them, but when faced with a choice that's good for one at the expense of another, higher priorities win

Though I will say:

> but for one-off scripts or anything operating in more of a batch mode it seems overly complicated

I disagree; I think I can make the reactive model ergonomic enough that it wouldn't be poorly-suited even to casual scripting. It may not benefit you as much there, but I don't think it will hinder you.