The reactive programming language one is really interesting. A compiler ought to be able to compile "normal" straight-line code into conventional efficient code. It's hard to know how that sort of thing would "pollute" the rest of the code, though, like, will every program turn into a rat's nest of dependencies such that it's just impossible to manage or what? Hard to tell without trying, especially since developing such a language would also require significant effort into developing a standard library and best practices to go with it even if the language was in hand today. And one hell of a debugger. Circular dependencies are a problem, too; I'm inclined to ban them but that's probably beyond what a type system can help you with, or at least, any type system I currently know, so it's going to be an adventure.

Still, there's a lot of things that would be more useful with such a language. In-memory highly-correct cache invalidation would become trivial code to write. In fact I think the cache would actually update itself live. Out-of-memory cache invalidation might be pretty easy. Certain auditing things would be easy. UIs would probably take some work to get right but would be interesting, at the very least. Game programming would also be interesting; a lot of game patterns would be incorporated into the language at that point.

Probably need to be lazy; I suspect proactively recalculating everything all the time would be a bad idea. Haskell has pushed lazy programming a long way, but "re-thunkifying" a previously calculated cell would be a new frontier.

Come to think of it, while I think the performance could be improved and you'd want to lift up to a full language eventually, I think a good Haskell programmer could bash together a prototype of this in a few days and start playing with it. It's going to need a lot of playing with before someone casts it into concrete as a language specification and corresponding compiler and runtime.