@Niclas,
Huh?
The standard midrange PIC architecture used in the PIC16C73 and PIC16F84, doesn't have vectored interrupts. If two interrupt sources trigger in the same cycle both interrupt flags should be set. If any interrupt flag is set, and not masked by the corresponding interrupt enable bit, or the peripheral interrupt enable bit or the global interrupt enable bit (GIE), GIE is cleared to mask further interrupts and the code at the interrupt vector (0x004) is called as if a CALL instruction had been inserted before the next instruction. The return address stacked is the next instruction. Execution transfers to the ISR and the application code must poll the interrupt flags to determine which interrupt(s) to service. Because GIE is cleared the ISR cant be interrupted, (unless the programmer is an idiot and sets GIE in the ISR). The ISR is then exited by a RETFIE instruction which does the same as a normal RETURN + sets GIE. If any interrupts are still pending, the next main program instruction address is stacked and the ISR reentered before the next main program instruction is executed, so an unserviced but enabled interrupt will hang the main program (unlike AVRs).
There is no way the bug could be as you describe. Perhaps 20 years later your memory is a little fuzzy.
There was a well known bug with clearing GIE to disable interrupts. If an interrupt was triggered in the instruction that cleared GIE, the ISR would be entered, and the RETFIE would set GIE again, which meant you had to use the code:
di: bcf INTCON, GIE ; Disable interrupts
btfsc INTCON,GIE ; Did it work?
goto di ; NO, so try again
to actually disable them successfully.
To set everyone's mind at rest, Microchip fixed the GIE bug before the midrange FLASH memory parts so the above code isn't needed for any PIC10/12/16 part with a F in the part number.