The stuff about “lying” should be disregarded. Using rebase or merge is not a moral issue. Well, it would be bad to rebase master or some other public branch, so don’t do that. Not because it’s lying but because it will cause problems and confusion. Screw it up bad enough and you’ll lose data.
The chain of broken commits is unfortunate, but add a bug fix commit and then rebase to squash it into whatever commit it belongs. The problem is the assumption in the feature branch that the dependency is still there when it isn’t. The problem is not rebase. The fix for the missing dependency has to happen somehow, squashing in a bugfix is a fine way to handle it.
When conflicts are introduced, I’ll agree that rebasing becomes a lot more painful and less useful. Rebasing through the constant stream of conflicts is maddening. It’s not clear what to do here, but repeatedly merging brings all sorts of ugly pain with it, like the fact that your branch ends up littered with changes that you didn’t make and are unrelated to the actual purpose of the branch.
I’ll close by saying that if you work in a fast-moving monorepo, rebasing becomes a more pressing concern.
