Aha! That is probably it. normally, there are 3 possible places this could happen:
We can rule the $9fff to $a000 transition out, because none of the code I'm putting there crosses banks (I assumed already that this was a bad idea knowing what I know about processors in general and boundary crossing).
Like you said, we can also rule the $bfff-$c000 transition out, because $a000 and $c000 are mapped to pages $1c and $1d respectively.
That leaves the $dfff-$e000 transition, and I'll bet if I breakpoint at the last instruction before $dfff, I'll catch this turkey, since I've noticed that the programmers at Nintendo didn't care too much about crossing bank boundaries, especially since this was originally a non-mapper cart.
I don't know what if anything I'll do about this if it is the problem, especially if it won't affect my abiliy to go to a dev cart, because I was hoping to leave as much of the original binary intact as possible for now, though I do have some more "advanced" plans that involve changing some of how the game works, such as extending the room change system to handle world #'s beyond 8. (I was thinking about a lookup table for this, where the "world" parameter of a room change object is actually an index into a table to find the world # for comparison, for those familiar with the SMB level structures).
I'll let you know what I find. I always follow the axiom of suspecting my code or actions first, but it's good that you're around to alert me to any known problems in OPC (other people's code).
Thank you very much for your help!