What are Iced/Elm's guarantees?

[sowbug]

In #1172 opened by @cbeust, @13r0ck says that manually passing messages (e.g., by calling update() yourself) "breaks all guarantees that the Elm architecture provides." I'm intrigued by this statement, because I'm still new to Iced and Elm, and I don't intuitively understand what such Elm guarantees might be. I know that view() ideally takes an immutable receiver, and update() obviously takes a mutable receiver, but otherwise I can't think of strong invariants that I've encountered. I also see various places in examples/ that do call update(), but I'd call those legitimate because they merely proxy messages to composable subcomponents (e.g., Task in todos), which doesn't feel like it breaks any of Iced's architectural elegance.

I'd appreciate if @13r0ck or anyone else weighed in on these guarantees. They'd be really helpful as I explore Iced and develop more judgment and expertise with my own design decisions. Thanks in advance.