Rather than a fork, I think what Elm could benefit from is a release branch. Let me explain…
Suppose you are working on some software system that is undergoing an ongoing R&D phase. At some point its nearly ready and your sponsor is needing to find some customers and ship it to pay for all that R&D. At that point you maybe do some tidy up on the mainline, and then take a release branch. On the release branch you do the necessary preparation work to ensure the customer gets a polished product - like adjusting the look and feel, integrating it with Active Directory for the clients single sign-on, add some custom database fields, stuff like that.
When the customer starts using the software for real, they are bound to do things that you did not anticipate, so you will get a stream of bug reports coming back from them. You fix these on the release branch, but you also apply these patches back onto the mainline. If you are smart you also first write a test to demonstrate the bug, then fix it, and add the test to the regression pack so that the bug never comes back, if somehow its patch gets overlooked on some branch (happened to me once, got called out by my boss on 31st Dec to fix a date rollover bug to 1st Jan at Client Co. and it was all my fault…)
After some more R&D, the next version of the software is ready. Customers may be slow to upgrade as it is not necessarily fully backwards compatible with what they already have - but you still have the release branch to support them until they are ready. When they upgrade, they get a completely new version from a new release branch.
So a release branch in some ways leads the mainline, because it is finding and patching bugs that feed into it. But on overall direction of the R&D, design of the system, features and so on, the release branches are downstream from the mainline project.
For me Elm is a goldilocks language, my favourite actually, I think overall the best programming language yet invented. So I would not want to fork it because I have no improvements to make to it as a language. But as people have noted before, its a bit of a walled garden. Thrust into the real world there is clearly an unresolved friction. That friction isn’t easy to fix, due to the way that the compiler and package system are tightly integrated, and the bottleneck on merging fixes back into it. That said, some of that friction has been very nicely fixed by third party tooling efforts along the way (thank you 
).
Now imagine that we had a release branch to handle the interface onto the real world. A place to fix issues, explore opportunities, support customers, and a place where those things could happen with less friction but a greater plurality of contributors.