SirGouki
commented
3 years ago I suspect this comes from javidx using the 6502 information, instead of actual NES hardware specifications. For anyone else coding an NES emulator and following along, you want docs for the 2a03(2a07 for PAL regions) chipset, which is a modified 6502 specific to the NES.
See here: http://wiki.nesdev.com/w/index.php/CPU_ALL for a lot of information.
Edit: added pal chip number
Edit2: upon further reading of the opcodes and registers, the U flag is expected to always be high (1) so it in fact should be added incase a rom checks this for some reason. There are also interupts that set B, and that all the opcodes perform the same, minus decimal mode functionality ) as a standard 6502, so any status flags that are valid on a standard 6502, save for D, should be implemented in an NES emulator. This also means that Homebrewers for the NES should be able to reasonably test their ROMs against an emulator and have access to everything save for Decimal mode behavior and it perform correctly, even if the instructions they use aren't used by "normal" games. Also, don't forget that the NES was derived from the Famicom, which was capable of operating like a then current home computer, so some "unused" instructions may be unused because the NES lacks the hardware addons the Famicom had.
Information was obtained from wiki.nesdev.com and from the EmuDev discord, from members who have worked on, or are currently working on, NES emulation.
Much like the U flag, the B flag in the status register doesn't actually exist in hardware. That means that reading the status register should always yield a 0 in the B flag place. The B register is only ever used when BRK or PHP are called to place a 1 in it's place on the stack. This is implemented in code only by guarding the BRK and PHP and hardware interrupt routines. But pulling a value with status flags from the stack and putting them into the status register (PLP) will set the Break flag, even though it should always be 0.