Huh? My whole comment is about the fact that they DID cause a lot of problems for production software. The company wrote their flagship product in Haskell, and there is a pretty large chance that that decision will doom them because of the choice to use Haskell. It's unfortunate because the product has a great market fit. If they had choose pretty much any other tech stack, they would be killing it.

I recall refractors from those proposal being very mechanical and easy to automate.

Maybe my memory is fuzzy... But if not can you give an example where that wasn't the case?

Yes. An example was moving to the version of GHC where the semigroup change happened. The codebase was using this library: https://github.com/brendanhay/gogol. The library dropped support for one version of Google's API for another version. Fair enough, except the old version would no longer work because of the semigroup change. So I ended up having to waste a ton of time completely changing on how we were using a library to satisfy the semigroup change.

Again, this is the problem. The ecosystem tends to only aim at GHC latest because of the attitude that "its mechanical to change!". Yeah, for the code you write maybe, but if the dependencies have that attitude, all of sudden upgrades can be a huge effort.

That seems like a problem with gogol dropping support for relevant features, rather than with the semigroup change in particular. If you didn't want to keep up to date with the library more generally, the semigroup change in isolation could have been dealt with by forking the library in question.

Which isn't to say this isn't still indicative of friction in the Haskell ecosystem when it comes to building a large system for production.

Would fixing it require more than adding

    instance Semigroup t where
        (<>) = mappend

for every type t that has a Monoid instance? That would be tedious for sure, and very frustrating that a maintainer wouldn't support their package sufficiently well to do that for you, but still seems to fall under the description of "mechanical".

> The company wrote their flagship product in Haskell

Which company are we talking about? I don't see mention of a specific company in your original post.

It would be unprofessional to name the company.

I'm not asking you to name the company! Your original comment talked in general terms that could be interpreted as hearsay. Your later comment mentioned "the company" as though we're supposed to know what that refers to. It suggests you worked for a specific company that got burned by Haskell. That makes your point of view significantly more useful!