There are a series of two byte opcodes (opcode byte plus MOD-REG-R/M byte) that have a MOD-R/M for a 32 bit register indirect addressing mode.
For example, one of these (of many) is add [eax], al and the encoding is 0x00, 0x00
In real mode this instruction (on a 80386 or better) requires an address override prefix byte (0x67) since there is no instruction for add [ax], al.
However, the encoding of 0x00, 0x00 is a perfectly valid instruction in real mode, and in fact is a true real No OPeration.
Unlike xchg ax, ax aka 0x90 which is a valid operation (but for the fact that it has no effect and is thus classified as a NOP), the encoding of 0x00, 0x00
in real mode (without the address override prefix) not only doesn't add al to what ax (or eax) is pointing to but does absolutely nothing other than
advance the program counter.
Of course, these undocumented REAL real mode x86 NOP opcodes are (almost) totally useless.
I did however manage to save 3 bytes (which I didn't need) in my exFAT boot sector boot loader.

16-bit address encoding is very different from 32-bit one. There is no such simple correspondence between them. "00 00" in 16-bit mode encodes "add [bx+si],al" and not "add [ax],al".

That explains why it has never been documented.
I guess I should have waited for April 1 before posting.
Funny thing is IDA Free won't disassemble 0x00, 0x00 as code.

No it isn't. Sounds to me like a bug.

W32Dasm write lots of 0 as db dup 0, but if the first instruction after them happen to be add r/m8,r8 then the dup cover 0 in instruction