As IWP has indicated above, it is more a case of a documented feature.
see note 4
Set the input conditions which cause an interrupt
picaxe.com
Accordingly, no “fix” has ever been considered.
The usual recommended method for those who do have pauses of extended duration has been, as you have mentioned, to place a shorter pause period within a loop to achieve the desired overall delay.
Consider the case where someone sought a pause of a very specific length - let’s just say 1 second.
Now an interrupt is introduced into the equation.
How long will the interrupt take to execute.
Ideally and recommended is the the INTERRUPT routine performs minimal actions and rather is used to set a flag to indicate to the main code that an Interrupt event has occurred. In this case the Execution of entire interrupt routine may be completed in say a few milliseconds.
However, other folks include the code for the entire reaction to the interrupt event within the interrupt subroutine.
Now there is the extended time for performing some maths and maybe a serial communications to a display so the total time may now be approaching that 1 second.
Therefore the question would be: how much time from the original pause must be allowed to complete the task to retain the original timing?
For those who use a loop and a short pause duration AND perform minimal tasks within the INTERRUPT routine then the overall sought timing will remain relatively close.
However, for those who include a lot of tasks within the interrupt routine then, it may be a case where the resultant overall timing is in fact extended beyond the original sought 1 second.