Basically, the fact that any kind of tweaking to the history in terms of comments or grouping together related commits into a single commit changes the hashes. This means that git's normally useful ability to check "hey is commit X in the history of both branches A and B" is broken.

That's a huge usability problem with git. Even as simple as a "rebase on merge" or "squash on merge" automation makes it impractical to push your topic-branch and keep working locally on that same branch while your topic-branch is being reviewed and tested, because git doesn't retain any concept of the fact that "this block of commits has been transformed into that block of commits and so you can consider them one-and-the-same".

I'm the git sme at my office and I deeply resent the amount of time I have to spent training juniors and students around git's jagged edges.

Ideally git should have a proper in-repo objects that reify a relationship between rebased/squashed/amended/etc commits and their predecessors and exposes that when you ask things like "hey is commit X in ref Y?" it could say "no, but there is a modified version of that commit".