I don't really think it's not-a-bug either, but it's the kind of bug that would break compatibility if $cb(N,,&var) started including $cr and $lf in the string by default, or $cb suddenly started working "correctly".
So the happy medium to get the correct behavior using a new switch that includes the missing data between a $cr and $lf. Whether there needs to be a -n0 or -n1 to have different flavors of this, i dunno. Such as whether or not to include the trailing $lf, and if not - whether to include 1-or-more $cr's touching the $lf, how to handle lone $cr's within the line, how to handle $lfcr etc.
But I don't think there was ever the intent to discard all bytes between a $lf and a $cr not touching it.
And I wasn't precisely correct when I mentioned that the line numbers were tokenized by $lf, because it doesn't behave like $gettok where leading/trailing/duplicate-consecutive $lf delimiters are ignored.
