This difference doesn't matter because of how zlib works. At least by default, zlib divides the input data into its own blocks independent of the caller. If you don't feed it enough data to complete a block, it waits until you feed it more or finish the stream.

We can test it by going back to zlib:

       def length_for(seq: bytes) -> int:
  -        return len(bz2.compress(context + seq, level))
  +        return len(zlib.compress(context + seq, level))

At temperature zero, this outputs the same sample as commit 3734bf6, the most recent commit upstream:

  MENENIUS:
  'Though all at once cannq

  MARCIUS:
  I'll fight
  'Though all at once cannq

  MARCIUannq
  
  MARCIUS:
  I'll fight
  'Though
  
  AUFIDIUS:
  If I fly, Marci
  
  AUFIDIUS:
  If I fly, Marci
  
  AUFID
  
  AUFIDIUS:
  If
  If I fly

I also tried LZMA for good measure:

       def length_for(seq: bytes) -> int:
  -        return len(bz2.compress(context + seq, level))
  +        return len(lzma.compress(context + seq))

The sample at temperature zero:

  MENENIUS:
  'Th
  
  A carbuncle enti
  
  , as big as thou
  
  
  A aa

This is followed by a lot of whitespace.

python-lz4 gives you all newlines after the prompt. I tried debugging it, and the compressed length of different candidate seqs is the same.