I wrote a blog post https://blog.poleprediction.com/clr-purescript-elm https://blog.poleprediction.com/clr-purescript-elm about this kind of thing. The main sen

I wrote a blog post https://blog.poleprediction.com/clr-purescript-elm https://blog.poleprediction.com/clr-purescript-elm about this kind of thing. The main sentence of relevance is "All libraries written for Elm, assume that the consumer is writing their application using TEA." It is semi-regularly noted in the Elm community that Purescript is a good counter-factual for Elm. Many requests for greater flexibility, such as access to kernel code for non-annointed libraries, have the pretty decent answer "well if you want that, go try Purescript". Purescript, though, is just a sort of closest-cousin here. I'd say most languages have a philosophy closer to "we're all adults here, anything goes, the more we let innovators innovate, the more productive we'll ultimately be". That's not to say the Elm approach is 'better' in any sense, but it does mean that it's a worthwhile experiment. It's different from most other languages in that it's way more restrictive. Those that ask for changes in Elm's approach, obviously have some other reason for wishing to use Elm, otherwise they wouldn't wish for Elm to change, they would just use something else. But those must acknowledge that whatever it is about Elm that is attracting them, may be as a result of Elm's unusual approach.