> The history is an end product intended to help others (often future me) figure out when and why things changed, preferably in self-contained, well organized steps.

Development is often not self-contained or perfectly organized, so we shouldn't expect this of the change history either.

> In the long term it only confuses whoever is looking through the history to figure out why something is the way it is.

Source control is the wrong tool for this job, that's what comments and tickets are for. Source control can help you retroactively figure out how and sometimes why something evolved in a certain way, like a good archaeological tool, but we don't use crude tools when there are better tools.

I've taken to literally embedding ticket numbers along with comments directly in the code and in commit comments to document exactly why code does what it does. All functional changes are tied to tickets [1], and the tickets contain the full context, and the code comments contain a summary of that rationale. Use the right tool for the job.

[1] where "functional changes" means changes that can affect behaviour, rather than stylistic changes on variable naming or revising comments that have no visible effects.