(The word "fork" appears once elsewhere, in an unrelated context in a different comment.)

The thing about open arms is not about forking (or if it is, it's not obvious to me), and reads to me more like "assuming you are not making your own fork, can you please stop pressuring upstream to accomodate designs which are explicitly against our clearly communicated design goals".

The quote is:

> @spookylukey It's one thing to build tooling around an implementation flaw without knowing the history, but that's all pretty well communicated at this point.

> If you understand the design goals, but don't agree with them, why not channel that in a positive way - e.g. by building something that fits your vision instead of directly working against Elm's design goals?

> As someone who has spent a lot of time collaborating with many others to help Elm achieve its stated design goals, intentionally working against those goals feels to me like an attack on our efforts. We have been really clear about our design goals in this area, and you shouldn't expect a project that works against those goals to be greeted with open arms—especially not from those of us who have been working hard for years to achieve those goals.

I still see no objections to maintaining a fork or local patch from rtfeldman. Just "if you go against our explicit design goals don't expect us to want to merge it upstream for first-class support".

TBH a locally patched compiler sounds like not a huge deal to me. I have lived with locally patched GCCs before :-)

But maybe I'm unusual. I surprised someone, once, when they found some code not working and I suggested they look at their compiler source for the cause. Their response: "Wow, I hadn't ever thought of the compiler as something that might have a bug, let alone read and modify it".