Because you added code to the interrupt method where the deregistration occurs. You're also missing URGENT so you can have an event that executes before interrupt which resumes the process. I have not tested this to be honest. I just had the feeling that doing this during the callback is too late.
If pull request 31 is to be merged, URGENT will not be used anymore for interrupts. But you may be correct if this pull request gets applied to the current tip. In that case, we are missing a test. I will take a look at this in more detail. Thanks for your review :)
I looked at the code again and I think there is no problem. What do you mean with "missing URGENT"? The Interruption is scheduled as urgent (see line 223), so normal events cannot be executed before the interrupt. Only concurrent interrupts may be executed before an interrupt and in this case I think it's correct to deregister the callback right before the process gets resumed.
In pull request 31 URGENT is not used anymore, urgent events are put in a queue, while scheduled events are put in a heap. In that pull request you added the removal of the target's resume callback at the same time the interrupt was created. This would be equivalent to removing the target's resume callback in the initialization of Interruption, rather than in the callback. See lines 279-281 in pull request 31 on events.py.
If I am not mistaken you would need to prevent the event req from waking up procA. But the interruption would be enqued after req's success. Therefore Interruption would need to unregister the callback of the process' target as soon as it is created instead of when it is processed.
But okay, this can be postponed to the point at which pull request 31 is to be merged.