> Your final paragraph hints at the kind of engineering that inevitably begins to appear as a workaround to solving the wrong problem in the first place. All of it is extra complexity that doesn't need to exist at all.

I agree it's extra complexity, and it's not strictly necessary. But it's not that much extra, and it doesn't affect pages that don't need it, which in the app I work on, most don't. (Whereas if all your pages take a top-level model, and return a top-level message, they all need to deal with that even if they don't need it.)

> Does prior experience with bad surprises in Elm give you this intuition? Or is it from experience from a language like JavaScript where global mutable state is indeed something to be wary of?

Not specifically Elm, I've only written it in one app.

But I'm imagining bugs where a page mutates its state in ways that satisfy some invariant, and then that invariant is violated and no one can work out how it happens. Turns out some other page is editing its state, in ways that probably made sense at the time. (Granted the debugger will probably help, but... I dunno, I'd rather just not have to.)

I'm not convinced large Elm apps don't have problems like this. And saying "no, if you want to communicate with another page, you have to do it through this specific mechanism" seems like a fine way of avoiding it.