It appears this is by design, where $cb(N,,&binvar) loads the &binvar with identical content to that received from $cb(N). It looks like the clipboard tokenizes line numbers by the $lf, but then fills $cb(N) by tokenizing that token by the $cr. Normally, this results in the line that everyone wants, where the $crlf or $lf is excluded. However if there are any bytes between the $cr and the $lf, they don't get included in $cb(N) nor in $cb(N,,&binvar). In this example, the foo doesn't go into the clipboard except if accessing the entire clipboard as line -1.
//clipboard line1 $cr foo $lf line2 | var -s %i $cb(0) | while (%i > -2) { noop $cb(%i,,&var) | echo -a line %i = $bvar(&var,1-) $bvar(&var,1-).text vs $cb(%i) | dec %i }
//clipboard line 1 $cr secret hiden from $ $+ cb(1) and $ $+ cb(2) $lf line 2 | echo -a $cb(1) $cb(2)
Perhaps another switch for the 2nd parameter, at least for the &binvar output, which avoids line-1 through line-last excluding all data between the $cr and $lf, as well as making it easier to find out whether then Nth line ended with $crlf or just $lf.
Something like $cb(N>=0,n,&binvar) could include all data through the $lf or end-of-clipboard.
Also bumping the support for loading binvar into clipboard like /clipboard -b &binvar
