Production is not some place you're supposed to cowboy code, but instead have a reasonable expectation that you will be able to continue supporting it for as many years as it operates, and it's impossible for anyone to responsibly use technology with known limitations that have bitten other real engineering teams that they can find zero workarounds for.
If you don't consider that an impossibility for a production environment, then I certainly wouldn't want to work with you on a team with production responsibilities.
If that's the level of discussion you want, I'll pass. And perhaps you should reflect on if you yourself is a great team member, if this is how you conduct technical discussions with your colleagues..
You'll note that I didn't get immediately riled up on you calling my original post "FUD" instead of asking why I said what I said. And then when I tried to clarify to you how I consider usage of Elm in production impossible, you again attack me directly instead of trying to discuss anything.
So, perhaps you should reflect if you're a great team member if you consider your opening statement to me to be a "technical discussion" at all? I was just trying to respond reasonably for third parties who are reading this, because I consider you a troll.
If you want to rely on them for every possible future requirement or rather want to pick another tool is another question :D
Anyways, just building the compiler without that check was also not that hard.
Elm's value proposition is mostly being a functional language with an opinionated MVU library baked in, so you can reproduce that value with a better functional language and selecting a similar MVU library in that other language, which means it should never actually cross the value bar above the risk it brings if you need a browser feature it doesn't support and actively prevents you from accessing.