The situation
You moved a paragraph, or a function, or a block of configuration. Nothing about its content changed — it just lives somewhere else now. The comparison reports it twice: as deleted from where it used to be, and as added where it now sits. Two changes, in different colours, for one edit that removed nothing.
The content is intact and the comparison is not malfunctioning. It is answering a slightly different question than the one you have in mind, and once you can see which question, the output stops being confusing.
Why sequential matching reports it that way
The classical way to compare two texts is to read both from top to bottom and find the longest sequence of content that appears in the same relative order in each. Anything inside that sequence is unchanged. Anything outside it has to be described as removed from one side or added to the other, because those are the only two things this kind of comparison can say.
A relocated block breaks the order by construction. If a paragraph that was third is now eighth, it cannot be part of a run that preserves sequence — including it would require the run to go backwards. So the algorithm does the only thing available to it: it reports the paragraph as gone from position three and as new at position eight. That is not a bug in the method; it is the method working exactly as defined, on an edit the method has no vocabulary for.
This is also why the similarity score drops. Both halves of that phantom pair count as unmatched content, so a document you did not remove a single word from can score surprisingly low.
What order-independent matching does instead
The alternative is to stop assuming that position identifies content. Each side is first broken into meaningful blocks — a whole function for code, a sentence or paragraph for prose — and each block is fingerprinted by its content. Matching then happens between fingerprints, wherever in the document they happen to be.
Once blocks are paired by content rather than position, the question of what moved becomes a separate step. The tool takes the matched pairs and finds the largest set of them that still appear in the same relative order on both sides. That set is the backbone: everything in it stayed put. Everything matched but outside it is what actually moved, and it is reported as a move — one change, with a connector linking where it came from to where it went.
The practical consequence is the one that matters. A file whose sections were reordered but not otherwise edited scores at or near 100% similar, because nothing was lost. In this tool that behaviour is the Smart mode, and sequential top-to-bottom comparison is available as Strict mode alongside it.
Why you would ever want the sequential answer
Because sometimes position is exactly what you are checking. If you are verifying that a file was not reordered — that steps in a procedure are still in their documented sequence, that a list is still sorted, that an ordered set of migrations has not been shuffled — then treating relocation as free hides the very thing you are looking for.
Both modes here feed the same similarity formula, so their numbers are directly comparable, and the gap between them is informative in itself. A high Smart score with a low Strict score is a precise signal: the content survived, the order did not. That is often the fastest way to characterise what a large diff actually did.
Moved and edited at the same time
A block that was relocated and also changed is reported as moved, with a similarity score on the row showing how much it was edited on the way. The headline number weights it by that score rather than crediting it in full, so a paragraph that was moved and had a sentence rewritten cannot report as a perfect match.
This matters when reviewing someone else's change. "Moved" alone means content you have already read is now elsewhere. "Moved, 92% similar" means it was also edited while it was in transit, and the edited part is the bit worth reading.
The limit: a move is not always safe
This is the part to take seriously, because an order-independent comparison is built to treat reordering as cheap, and reordering is not always cheap in reality. Two statements that both write to the same variable cannot be swapped without changing what a program does. Two clauses in an agreement may derive meaning from what precedes them. A step moved before the step it depended on is broken, and a comparison that scores it 100% is telling you the truth about content while saying nothing about behaviour.
Where a relocated block reads or writes state that a neighbouring block also writes, the row carries a caution marker: reordering may not have preserved behaviour. It is advisory and deliberately conservative — it flags the possibility, not a proven problem, and it cannot catch every case.
So a near-perfect Smart score means very little was added or removed. It does not mean the two versions are equivalent. When sequence carries meaning, check the moves rather than the score — and how to read a diff covers the rest of what the output can and cannot tell you.