NES mapper programming sounds like shitposts or elaborate pranks.
For example, MMC1. Super common chip, used on Metroid, Legend of Zelda, Bionic Commando.

To program it, you simply write five bytes to the upper half of the memory space. The LSB of each byte is added to a shift register and then for the 5th byte the 13th and 14th bit of the address are used to determine which register to program.

this is the kind of thing you'd expect to happen as part of some kind of tricky DRM system but no, the NES's DRM is implemented completely differently (and outside of the view of the CPU).

this is just how you bank switch on the MMC1

also there has to be at least one cycle between writes, or it ignores them. This is intentional behavior because of a weirdness of the 6502 where any instruction that modifies memory does two writes, once with the original value and once with the modified value.

emulating this behavior correctly is required for at least two published games, because of course it is

also some PCBs didn't bother connecting pin 14 to the MMC1.
So this behavior is different, and only address bit 13 matters.

This means you can have two games with the same ROM and the same mapper chip, but they work differently because the PCB is different.

one of the registers you program with this interface is used to select the PRG-RAM bank, which is the 4th bit on the CHR0/CHR1 registers... except for one game, A Ressha de Ikou, where it's the 5th.

it doesn't affect the MMC1, but the way some mappers are implemented on the NES also leads to a fun situation where your code needs to make sure the writes to ROM are only ever "writing" over the same value

this is caused by a bus conflict with the mapper and the CPU confusing the mapper. you try to write a 5 to $8000 to program the mapper, but the mapper has mapped 0 to $8000 and the 0 wins.

so even though the mapper is listening to writes in the entire top half of the address space, you gotta make sure the ROM has the correct values to write over, or it won't work.