apparently valid instruction, it clears r16. (tested under a debugger)
(does not touch eflags either, didnt test in 64bit mode tho)

some research:
https://gynvael.coldwind.pl/?id=268

but it used to do something different on 486 or specific versions of it:
https://www.df.lth.se/~john_e/gems/gem000c.html

By itself, the bswap instruction for r16 is similar to xchg rl, rh. It was introduced so that it was possible to operate with the highest word in 32-bit registers.

yes I know and understand bswap r16 is useless, but intel says it is undefined, while the behavior is stable for more than two decades and some software rely on this.

but I believe they had to do something about operand size prefix, if I were to think from engineering perspective, then it is probably best option to allow operand size prefix and do almost nothing instead of generating #UD. which is likely the decision intel made here.

Make sure that 0 is not being pushed into eax by the standard #UD handler.

The code produces the same result in 32-bit and 64-bit modes, it just zeros the lowest 16-bits of r32/r64.

An advantage to using it is that it is 3 bytes to encode, instead of 4 bytes for mov r16,0.

A disadvantage to using it is that it is undocumented, and future CPUs, or CPUs made by other manufacturers, might do something else.

I doubt intel will change this, but yes valid point 3rd party x86 vendors and/or clones may have different operation.

been querying some intel manuals, specifically in topics related to instruction prefetch and predecode steps of modern architectures, length changing prefix such as operand size prefix can slow down decoding of fetched instructions (*), from typical 1 cycle to 6 cycles, except REX length changing prefix dont have this penalty.

(*) not always, it seems intel only discourage using operand size prefix with word immediate. so bswap r16 isnt affected, but that does not change the fact one should not use bswap r16.