To be clear, I am not stating that
QB64 output eats NUL bytes, I'm saying that a normal DOS or Unix terminal eats NUL bytes. As far as I know, QB64 emulates its own terminal outputs and does not use standard DOS, Unix, Mac, or Windows terminal outputs.
In terms of
how QB64 should behave, it should respect that CHR$(0) is not meant to be a printable character in Unix, DOS, or QuickBASIC. CHR$(255) is meant to be a printable character, which is visually the same as a space character, but with a different character number so it isn't actually a space. In the original QBASIC, INKEY$ displays special keys as a NUL byte + another byte. The NUL part was never displayable, which was a touch confusing when first learning INKEY$, as it appeared to be returning a single character when pressing arrows or F-keys or whatever. Had to use LEN() on it to make any sense of it!
I just tried this command on a GNU+Linux terminal to confirm:
The NUL byte gets eaten, all that is output is the two braces by themselves.
printf '[\x00]\n' | wc --bytes
4
This returns "4" as expected, the two square bracket bytes, the NUL byte, and the Unix newline byte. The NUL byte is there, but it is not displayed.
Please note that there are tons of non-display characters in terminals, such as ANSI codes. There are also a lot of special terminal characters, such as the TAB character CHR$(9) / Ctrl+K which brings the cursor to the next horizontal tab stop, or BEL character CHR$(7) / Ctrl+G which tells the PC speaker to issue a beep sound.
Speaking of which, does the QB64 emulated terminal support ANSI colour codes?
QuickBASIC used the standard DOS terminal for output, so it supported ANSI codes if your version of DOS supported ANSI codes.
I just checked, and QB64 does not support ANSI codes. It displays the ESC character CHR$(27) as a left-pointing arrow.