"Simplifier ticks exhausted" that resolves with fsimpl-tick-factor=200

This is perhaps the same bug as #10527 (closed) but I'm not sure, as it goes away with a modest bump to -fsimpl-tick-factor.

I'm developing a library and am seeing this when I go to compile a small hello-world executable.

<no location info>:
    ghc: panic! (the 'impossible' happened)
  (GHC version 7.10.3 for x86_64-unknown-linux):
	Simplifier ticks exhausted
  When trying UnfoldingDone $fMonadIdentity_$c>>=
  To increase the limit, use -fsimpl-tick-factor=N (default 100)
  If you need to do this, let GHC HQ know, and what factor you needed
  To see detailed counts use -ddump-simpl-stats
  Total ticks: 6642

If I remove the INLINE from the exported functions it goes away, but also makes the code much slower (for some reason the way I use the function in my benchmark suite doesn't exhibit the error).

It also compiles with -fsimpl-tick-factor=200.

Previously on 7.10.1 I got the same error in a different part of my code (the benchmark suite) which went away when I moved to 7.10.3. If it's helpful I can upload the state of my library repo, but it's not a small test case.

Even if this is a duplicate, I'd love some guidance on this: Is this actually a ghc bug, or is it my fault that I've got too much inlining in my code (I've never seen anything like this before, and pretty much mark everything INLINE)? Should I pass this off to my users and should it be their responsibility to bump -fsimpl-tick-factor to work around regressions in their GHC? If I want to try to work around this in my library, what strategies could I employ (besides disabling inlining of exported functions), and how do I know whether this won't blow up in the same way for users anyway?