Appending multiple line to the same binvar means that if you are using $bvar().text, you'll get the first line only (so, because of the binary 0 added), and if you were just going to append multiple lines and then handle the bytes manually, well the binaries 0 are just extra. So these binaries 0 didn't make sense at the time.
As far as the dispecrancy between $sockbr, $sock().rq and the length of the binvar goes, it's totally correct behavior. They are all independant features.
For example for http, if you wanted to make sure you received the expected number of bytes, you would first store the content-lenght value, and then decrease that value by $sockbr each time you sockread REGARDLESS of how you read the data.
You would never decrease that value by either $bvar(&var,0) or by $len(%var) because they are not meant to return what was really read from the received buffer.
In pretty much any socket script, $sockbr and $sock().rq will be different unless that script specifically reads all the bytes available with "/sockread $sock($sockname).rq &bv". "/sockread -n &bv" reads a line (not a line + extra bytes), it should be expected that $sockbr and $bvar() will have a difference in length of either 1 or two, depending on if the line was ending with $crlf or $lf.
Considering binvar are used to overcome the line length limit, it makes sense for a script to handle manually the byte in a binvar filled by /sockread -n, since trying to get all the text with $bvar(,1-).text would fail. Though it's not everyone who do that, which is why I think it should be ok to fix this.
I was not there at the time of the implementation, but to me, it is pretty obvious the feature was only tested using $bvar().text, which does not show the issue. This was missed, it was not considered okay.
