There are at least 4 relevant pieces of text in the POSIX.2018 specification of
Emphasis (bold text) is mine in all the quoted text below:
Input files to the awk program from any of the following sources shall be text files
That means that if the input contains NUL characters (which would make it non-text as per the POSIX definition of text), then the behaviour is unspecified.
\ddd : A <backslash> character followed by the longest sequence
of one, two, or three octal-digit characters (01234567).
If all of the digits are 0 (that is, representation of
the NUL character), the behavior is undefined.
\000 results in undefined behaviour.
About regexp matching:
However, in all awk ERE
matching, the use of one or more NUL characters in the pattern, input record, or text string produces undefined results
7. For the c conversion specifier character: if the argument has a numeric value, the character whose encoding is that value
shall be output. If the value is zero or is not the encoding of any character in the character set, the behavior is
So, that's another way to get a NUL character that leads to undefined behaviour.
So, to sum up, in
awk, POSIX tells us you can't use the NUL character portably, whether it's for input, output or to store in its variables.
gawk (since at least 2.10 in 1989 which is the earliest version I could find where NUL support is documented) and @ThomasDickey's
mawk (since version 20140914) are two implementations that can deal with NUL.