Submapper when autodetection possible? (Mapper 176)

Mapper 176 (FK23C[A]) uses three incompatible variations (and there are probably more variations that are however compatible from an emulation point of view):

1. Normal. Initial PRG Bank at CPU $E000 is the very last 8 KiB PRG bank within the first 512 KiB, based on the FK23C starting up as an MMC3 clone;
2. Extra 32 KiB PRG-ROM Bank containing menu code, mapped into the address space as a second 512 KiB bank (with the initial 480 KiB in that second 512 KiB bank empty). Initial PRG at CPU $E000 is the very last 8 KiB bank within those second 512 KiB. Same thing with CHR-ROM. These are multicarts for which the menu code could not be squeezed into unused sections of the original 512 KiB;
3. Swapped MMC3 registers $46 and $47 (but not $06 and $07).

Variation 2 can be detected by the fact that all ROM images using this variation have 1024 KiB PRG-ROM plus 1024 KiB CHR-ROM, and no ROM images with those sizes do not use this variation. Variation 3 can be detected by the fact that all ROM images using this variation have 16384 KiB PRG-ROM.

Should submappers be allocated for those, or does the fact that they can be autodetected from the sizes alone make submappers dispensable? (Or are pirate multicarts maybe not worth the effort of allocating submappers?)

My feeling is that, if unified code (like MMC1 and SUROM/SXROM, where "if PRG A18 exists it's always controlled using the CHR register") can be written, then no submapper is necessary.

On the other hand, if altogether different code has to be selected based on load-time heuristics, then it should be submappers or possibly even an entirely new mapper altogether.

I have rewritten the Mapper 176 wiki article. Oof; that's probably the most complicated mapper article that I have written so far.

The information is based on debugging many of these games myself and verifying the results through Nintendulator emulation (attached, still lacks an adjustable DIP switch feature), which runs all applicable games that I could find perfectly, as far as I can tell. In particular, it goes to show that the Waixing Mapper 176 and FK23C multicarts are not separate mappers assigned to a single number, but compatible variants of the same hardware at worst.

Fun fact on the side: whoever put the Rockman I-VI FK23C multicart together deserves my praise for fixing Capcom's sloppy IRQ programming on Rockman 3's level select screen.

Rockman I-VI FK23C ,I public version Rockman 3 bug is cart bug.
这个合卡，我发布的，洛克人3的BUG是合卡自身的。真实机器也这样。没有BUG的ROM，我并没有发布。

version 1.rockman 3 IRQ bug.
version 2.not have bug fk23ca
version 3.dumped,but not 176,uneum.

版本1，发布了，RM3 IRQ有BUG
版本2，没有BUG，但没有发布。
版本3. DUMP了，但不是176MAPPER，没有模拟。

Small update to the previously-posted Mapper 176 source file involving the initial state of the MMC3 bank registers. This only makes a difference for 星河战士 (Xīnghé zhànshì), the Hengge Dianzi version of Waixing's 外星戰士 (Wàixīng zhànshì).