That's not a bug, in that 'split' is behaving as documented. The first
input line is one byte shorter than the second one. 'Split' divides the
input into two regions, and because the first region happens to be one
byte longer than the second region both input lines are sent to the
first output file.
In older coreutils, 'split' used a different algorithm to compute region
sizes, which worked better for your test case but considerably worse in
others. For example, in older coreutils:
seq 50 >in
split -n l/71 in
created 43 files of size 0, 9 files of size 2, 18 files of size 3, and
one file of size 69. Current coreutils splits much better: it creates 21
files of size 0, 9 files of size 2, and 41 files of size 3.
