The change was handled extremely poorly. I only knew one team using Elm in production at the time. They went from being huge proponents of Elm to recommending against it after the 0.18/0.19 changes and drama upended a lot of their work.
There may have been a "right" way to do things under the new version, but breaking major functionality in a minor release without warning is a sign that you don't really care about your users. Changes like this require discussion, warning, and long transition periods.
It was bad enough that they got it wrong, but then Evan doubled down by dedicating the opening of his next conference talk to mocking the users who were unhappy about the changes: https://www.youtube.com/watch?v=uGlzRt-FYto
The part where he mocks a commenter for asking "Is Evan killing Elm's momentum?" is weirdly prescient, given that these events ultimately did mark the slowdown of the Elm community. Elm development came to a near halt about a year later.
> And it being open source means nothing stops you from forking it and adding your own native modules. Reason no one has done it is it's no need, and doing thinga that way would break the promises the compiler makes about no runtime bugs.
I disagree. Maintaining an in-house fork of a compiler just to accomplish what could be done with past versions isn't a reasonable suggestion. The reason people weren't maintaining in-house forks of the compiler just to keep their projects going was because that's a silly thing to do when you could just use any number of more reasonable mainstream projects that don't require such extreme lengths.
It's weird to see people casually suggest "Just maintain a fork of the compiler" as a reasonable solution.