That is, should graphicsmagick account for quirks introduced by imagemagick? If it's meant to truly be a drop-in replacement versus one with some strings attached, I would say the answer is yes. Otherwise, you can't easily just drop it into a system and let it run.

Systems built with libraries around long enough as imagemagick likely have all sorts of workarounds built in over the years for that kind of behavior and any deviation from imagemagick might break things more than one expects. We've all been bitten by libraries that claim backwards compatibility with previous versions, only to find out there's breaking changes in some non-trivial use cases the library devs didn't consider. Add those complications on top of switching to a library that is supposed to be a drop in replacement and it can get pretty messy for what seemed like a trivial task.

The last time I made heavy use of ImageMagick/GraphicsMagick, I was suprised how often I would find a feature present in one and not the other (often things like drawing gradients).

And it's not like one has a superset of the other's features: I once painted myself into a corner and created a project that depended on both ImageMagick and GraphicsMagick.

More info on the reason for the fork (at the time)