I went on a bit of a twitter rant about this recently, but I look a the bugs in the core libraries and I’m honestly quite impressed by how few of them there are that are actually critical and how many have straightforward workarounds - often just implementing a different function that checks inputs and short circuits in some way or otherwise behaves differently.
If I was looking to make the situation around bugs in the core libraries better (I think it’s fine, honestly) and I had the time to put in (which I definitely don’t) I would do something like this:
Look at the issues @rupert has collected (It’s a nice and thorough list). Anything that can be fixed with a wrapper function, or can otherwise be improved in pure Elm, put it in a library. Call it “elm-sandpaper” or something because it’s smoothing the rough edges. Also drop some elm-review rules in there that can disallow usage of the core version and suggest the sandpaper version instead. When you’re happy with the implementation, leave a little comment on the relevant issues saying “Hey there are workarounds for this and several other issues that you can find here…”
For things that affect kernel/JS code, JS transformation seems to have been broadly successful, so provide some tools for that, maybe piggyback off of elm-optimize. I’d put big warning labels on it to point out that if you use it to run Elm in places it’s not designed for like phones, electron, etc, there’s no guarantee of continued support.
For any significant doc issues, write some nice tutorials that point out important caveats to the docs. Brand them under the same “elm-sandpaper” project. It’s not the primary source, but most developers start with tutorials before API docs, and if these things are common knowledge in the community, people will easily find fixes, particularly if there’s a well-known set of folks providing those answers.
All this is not to say that I think folks shouldn’t fork the compiler if they want to. If that seems like a nice solution to you, or an interesting space to work in, go for it. To me, it looks like there are much simpler solutions available with far less overhead.