Good point!  Changed now.

A groff behavior has mystified me for many years, but never enough for me to delve into its cause.

The mystery is this.  Periodically I would make some change to the underlying troff code of a document that had no visible effect on the rendered page.  Yet there would be a huge number of changes in the generated PostScript code, every one of them some page movement changing by exactly one one-thousandth of a point, or one "basic unit" for the PostScript device, or a bit over .00001 inches.  In other words, effectively no change.  But any actual (visible) changes that might also have happened were obscured by all these false positives.

At last, thanks to Branden's analysis in bug #60665, I know what's been happening: Something changed the pattern of the "direction" that lines were adjusted.  Each subsequent line was then adjusted in the opposite "direction" from what it was before, causing a raft of invisible changes from that point on.

It turns out, once you know the mechanism, that the effect is easy to illustrate, using the observation (from bug #57836) that a diversion, even if never output, still affects the direction of adjusting.

Consider this example file.

$ cat honest_men
.ll 3i
.di ignore-me
S.O.S. and red alert, all across the universe, calling all honest men.
.br
.di
S.O.S. emergency, sinking fast and getting worse, where's your honest men?

It defines, but never uses, a diversion, then outputs text that spans two output lines, the first of which gets adjusted.

But the very act of defining the unused diversion changes the reversal pattern of the adjustment algorithm.  For comparison, remove the diversion definition, and output the same text.  This results in the following PostScript code diffs:

$ diff <(groff honest_men) <(sed '/^\.di /,/^\.di$/d' honest_men | groff)
233,234c233,234
< /F0 10/Times-Roman@0 SF 2.913(S.O.S. emer)72 12 R(genc)-.18 E 4.213 -.65
< (y, s)-.15 H 2.913(inking f).65 F 2.914(ast and getting w)-.1 F(orse,)
---
> /F0 10/Times-Roman@0 SF 2.914(S.O.S. emer)72 12 R(genc)-.18 E 4.214 -.65
> (y, s)-.15 H 2.913(inking f).65 F 2.913(ast and getting w)-.1 F(orse,)

The only differences in the output are in the thousandths place of the horizontal movements: 2.913 becoming 2.914, 4.213 becoming 4.214, and so forth.  Similar "changes" are visible in diffs of groff's intermediate output ("groff -Z"), so Deri's suggestion in bug #60655 is no help here.

It would be better if groff didn't inject invisible changes into output.  And it seems to be a conceptually simple fix: distribute_space() simply needs to be aware, or told by its caller, whether the granularity of the space it's adjusting is visible without a microscope and a ruler with nanometer marks, and choose whether to do its alternate-line-reversing trick accordingly.

(This, incidentally, simplifies Branden's dilemma in bug #60665 of how to describe this reversal algorithm to the documentation reader without bogging down in implementation details for devices where this algorithm produces no visible effect.  Get rid of invisible effects, and the documentation no longer has to worry about it.)