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.
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".
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.