I've thought more about the above. What would be nice would be if this could be a native instruction:
Signal=0 ? PC = (RAM @ vPC++) * 16 : PC = Vector
That improves the previously proposed native instruction that acts as vCPU Fetch/Dispatch. The idea is to put the native JMP based on RAM @ vPC as the last instruction in every vCPU "microcode" group instead of a hard jump to a central handler. That would form an infinite state machine. That is fine since you have a single instruction to fetch the new instruction, start the Decode process, and increment the address. It would be a dedicated new register and would not preclude using the other registers. However, what if you want external events?
So if I want to build something inspired by the Gigatron that has a Harvard core, but is only used as the CPU, with other devices handling the I/O, then it's going to need to handle interrupts and perhaps DMA. So back to the question. Modifying the proposed instruction to act in more of a ternary fashion would let it break out of the ISM. Without the ternary part, you'd have something that is infinitely running out of the same 4K block of ROM. But to coordinate with other devices, it would need to run other code.
So if you need to run a native interrupt, the vector hook would poll the signals (the IN port can be repurposed) jump to whatever handler is needed, and restart vCPU execution when it is done. For hardware-initiated vCPU interrupts, the code after the jump to the vector would save the vCPU state and change vPC to the routine, and issue the Fetch/Dispatch instruction. So the vCPU code is running at the new location. Then the IRET is reached and the state is restored to what it was previously.
The above mechanism can optimize function calls too. The Syscall instruction (vCPU opcode) would work like a prefix. Just running the Syscall instruction would point vPC to the function number (it doesn't need to be fetched as an operand -- treat that as an instruction). Then it would set Y (for the upper nibble to be correct) and use the same opcode that ends nearly every vCPU opcode handler. So it treats the syscall itself as any other vCPU opcode. To get back to the main one, it can set Y back to the vCPU handler page and then use the universal native Fetch/Dispatch opcode.