What follows is copy/pasted directly from code comments in src/diff.c, reformatted slightly to account for markdown/ticket system quirks:

An annoying cosmetic bug: the libf diff builders will sometimes render two directly-adjecent chunks with a separator, e.g.:

```
$ f-vdiff --format u 072d63965188 a725befe5863 -l '*vdiff*' | head -30
Index: f-apps/f-vdiff.c
==================================================================
--- f-apps/f-vdiff.c
+++ f-apps/f-vdiff.c
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    36     36    fsl_buffer fname;
    37     37    fsl_buffer fcontent1;
    38     38    fsl_buffer fcontent2;
    39     39    fsl_buffer fhash;
    40     40    fsl_list globs;
           41 +  fsl_dibu_opt diffOpt;
           42 +  fsl_diff_builder * diffBuilder;
    41     43  \} VDiffApp = {
    42     44  NULL/*glob*/,
    43     45  5/*contextLines*/,
    44     46  0/*sbsWidth*/,
    45     47  0/*diffFlags*/,
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    46     48  0/*brief*/,
    47     49  fsl_buffer_empty_m/*fname*/,
    48     50  fsl_buffer_empty_m/*fcontent1*/,
```

Note now the chunks before/after the second `~~~` line are consecutive
lines of code. In fossil(1) that case is accounted for in the
higher-level diff engine, which can not only collapse adjacent blocks
but also does the rendering of chunk headers in that main algorithm
(something we cannot do in the library because we need the fsl_dibu to
be able to output to arbitrary destinations). We can currently only _partially_
account for it, eliminating the extraneous `~~~` line only when we're in
line-number mode. (Note that the current code does so, so does not show
the chunk separator for the above case, but it will if the `-l` flag is elided.)
In non-line-number mode we _have_ to output the chunk header as-is.
If we skip it then the _previous_ chunk header, if any, will contain incorrect
numbers for the chunk, invaliding the diff for purposes of tools which import
unified-format diffs.

It would seem that the only workaround for that, within the current API,
is to always look ahead one chunk before sending the previous chunk to
the diff builder. That would allow the diff algo to retroactively adjust the
chunk line numbers/counts before passing them on to the builder for rendering.
It would, however, add a significant amount of complexity to that algo.