You shouldn't be getting code errors before the vector table has been copied to RAM, it only takes a few dozen cycles to copy the most used vectors. A bus glitch or even a hardware interrupt shouldn't be happening this soon after a reset, if they do something is probably broken and nothing I know can protect you from hardware that just doesn't work.
Since we're bringing the address bus, data bus, and presumably some IRQ lines out to expansion headers a user could very easily see problems creep in when something's plugged in that the system designer will never see. Such problems (too much capacitance, cross talk, etc.) can be notoriously intermittent and/or hard to replicate. It isn't that the hardware "just doesn't work," but that it mostly works, or that it always works right up to some point in executing the code, then crashes. Such problems aren't solved with properly initialized exception vectors, of course, but I pity anyone having to debug a system where the code executes correctly until just before the exception vector he/she is accidentally triggering is valid.
A lot of these types of issues could be helped by inserting bus buffers into the design between the onboard busses and the headers for the bus signals. I'll look at doing that, since I'm wanting to design the "student" version. That won't protect from premature IRQs, of course.
Someone who is writing code that uses the RESET opcode to assert the reset line should be at least a bit familiar with the hardware to be doing such a thing so it's not a huge ask to expect them to know this. However this can easily be avoided entirely by either gating the shift register reset with the halt signal or simply using the power on reset signal to reset the shift register.
Regarding using power up reset to clear the shift register, I had the same thought.
I like this solution a lot because it is about as transparent a solution as you can get and unlike solutions that use a port bit it requires no code to work. It also works for all bus widths, just use a different output, so the same circuit can work for all processors.
I was thinking of doing remap completely in my address decoder CPLD, in which case the circuitry issue becomes irrelevant, and I can put off the decision 'till later. For what it's worth, my original idea was that a remap flip-flop would be set one way when a power on reset pin is asserted, then be set the other way by a CPU access to some specific address or address range the CPLD could decode--the first access to an I/O address, for example. For that to work, however, I'd have to mirror SRAM somewhere in the address space to allow writes to the exception vector table while remap is active. BIOS-es written for the two methods would be incompatible.
Maybe I'm being paranoid, but I've still got a rather sore "bug bite" from a boot code issue where I work. A project of mine from 2011 was delayed for more than six months while we tried to find the cause behind some percentage of the PCBs occasionally failing to boot. In the end we learned that on that particular microcontroller, resetting the watchdog timer right before writing the watchdog timer configuration was bad. Nowhere in the chip manufacturer's documentation did it *say* it was a bad idea or that it could be a bad idea--they told us this after they were finally able to reproduce it on their end and admitted we'd helped them discover an erratum in their silicon.
When the product exhibited the problem it showed up as a continuous reboot "loop" where the firmware would execute just fine until the watchdog was configured, then reset itself, then repeat. Whether or not the reboot happened was dependent on the phase between the CPU clock, which was crystal-controlled, and an internal RC oscillator. Because of this it was highly dependent on temperature and even physical force applied to the MCU. Anything that changed the frequency of the RC oscillator, and thus its phase at the critical moment, was a factor. Take a PCB that was in the reboot "loop" and twist it, and it would stop rebooting. Take one that wasn't rebooting and twist it, and you might trigger it. We also found by trial and error it didn't happen at all with certain watchdog configurations.