Perfect way to describe it, thanks!

While testing a new feature we ran into this situation which, at the time, we could not explain. Why was the form not updating?!

It turned out that the particular form input also had phx-debounce, to avoid flooding the server with phx-change events, and if no such events were sent before submit, then the form state from the server’s perspective never changed, and the form input was not re-rendered and cleared!

Your account of the problem was key to realizing what was going on

What is actually going on here is that LiveView’s declarative abstraction is fundamentally leaking its imperative implementation. This is the sort of bug that is not supposed to happen with a declarative programming model.

In e.g. React this is fixed with controlled inputs which always have their state forcibly reset in lock-step with the render (this is declarative programming). Unfortunately this is one of very few things that I think genuinely cannot be fixed in LiveView because it is a consequence of server latency. In almost every case server latency is not a problem, but here it actually is.

This also means that @bartblast should take note, as if he implements controlled inputs correctly this is a case where Hologram will just be strictly and unavoidably better.

Concurrent changes to a shared input value between the client and the server under latency are not trivially handled. You run into all the problems of distributed computing there. Even client side libraries in the past got this stuff wrong - and they didn‘t have a network on the path. LV does.