From early in the article: > This [flat Msg design] does work, but at some point it becomes cumbersome to support a large number of constructors. As guessed,

From early in the article: > This [flat Msg design] does work, but at some point it becomes cumbersome to support a large number of constructors. As guessed, I'd personally stick with the simpler flat approach the article acknowledges and then tries to improve on. Nesting that data structure is (according to the article) an ergonomics improvement, but then the rest of the article is about how to solve ergonomics problems caused by the very nesting that was supposed to make things nicer! Given that, surely it's reasonable to raise the question of whether this nesting was actually an improvement after all. My conclusion at the end of the article is that in retrospect nesting did more harm than good, and knowing that, I would have happily left it flat. Incidentally, "leave it flat" is not my stance in all cases. For example, I gave a whole talk that could have been titled "when to nest" - https://youtu.be/DoA4Txr4GUs https://youtu.be/DoA4Txr4GUs - and my most popular Elm project uses nesting in multiple places - https://youtu.be/RN2_NchjrJQ https://youtu.be/RN2_NchjrJQ But indeed, in this case, I'd happily leave Msg flat and not bother with all the lens stuff!