Yes, I think this is correct. People committed to using Elm worked around a number of issues because to them it is still a net benefit, but I’ve seen a number of people moving ahead with other platforms because of it or partly because of it. They call it production ready but I would say it is production ready only if your use case is supported and you are happy to not have any fixes (But as mentioned they say this is going to change with 0.19)
Another point is that
elm/core is just one part of it. Because elm is a sort of mixed language/framework this changes the dynamic a little bit. For pure language and compiler work I agree that things need to be well designed and I understand if new versions take time. This is also used as a defense for the “long” release that other languages have had long release cycles as well. On the other hand, there hasn’t been a single update to the framework/library side of things either and as @OvermindDL1 mentions, a number of bugs and pull requests have been directly closed because they will refactor/rewrite to 0.19.
It depends. I think Elm is fine but I don’t like uncertainty. There are things I need which are not in Elm which makes it easier for me to use other solutions. But I also prefer to know where things are heading, when releases are coming, so that I can plan resources for it.
To some degree I think developers are like the stock-market. If they are uncertain about a product most will not invest. Some will make a gamble which may or may not pay off. Most of us like the index funds that just slowly keep improving without surprises. Currently I have no idea where Elm is going or what is happening and I am not prepared to gamble.
I don’t know if it was a big deal or not but the wording of the commit message and the large number of additions/removal seems big. They repository added 2k lines of code for the migration. At a glance it hard to see what has changed as a large number of files have been renamed. And there may have been more files added than just to upgrade to 0.19 but it looked big.
I know it is not 1.0 yet so breaking changes are part of the game but if you need to take advantage of any fixes/features in 0.19 you must do the work. And it is going to be more work than just updating a single library to a imaginary 0.18.1 package with only a few bug fixes but still full compatibility.