NES Pictionary Code Analysis

To understand why there's a ROM corruption bug in the Pictionary ROM we need to understand a little about the layout of an NES.
The NES uses a 6502, which uses a 16 bit address space.  Of this, code, can generally be mapped to two seperate sections, at 8x000 and 0xC000 in blocks of size 0x4000.
A typical NES game like Pictionary however has 8 of these blocks that might be mapped.  This is done using a separate Mapper chip on the cartridge.
The NES system (and the 6502) does not in general have any idea what is being mapped at any given time.
Now, for the Pictionary PRG ROM, we have a layout as follows:
Bank 0 Code/Data
Bank 1 Drawing suggestions
Bank 2 Pre-drawn words
Bank 3 More pre-drawn words
Bank 4 Even more pre-drawn words
Bank 5 Credits
Bank 6 Code/Data
Bank 7 Code/Data
Now, two things to note about the Pictionary ROM. 1) Like any 6502 program, there's jump vectors at FFFA, FFFC, and FFFE. and 2) The reset vector for this game is at FF00.
Now, how can you practically reset at any time, without knowing the state of the mapper chip? You copy the vectors and reset routine to every block!!!!
That's exactly what they did. Of each bank of 0x4000 bytes the last page starts with a 0x2b byte reset function, which basically puts the mapper in a known state, and ends with the 3 6502 vectors.
Now, surely this shouldn't be too much of a problem, you just need to make sure you only use 63 of the 64 pages of each block right? And they did...sort of.
See, the last page of bank 2 is a word entry of NOT_USED.  However, at the end of banks 3 and 4 are the entries DRAINPIPE and BUCKLE respectively.
These entries really should've been something like NOT_USED2 and NOT_USED3, as they are partially overwritten by the reset code.