Art,

First of all, let me say that I "assume" you are using DT's Instant Interrupts in the context of this question.

That being said, I am highly confident that DT "Adds" the Timer1 Preload constant (TimerConst) to the value of the Timer1 Counter
to account for the instructions executed in his Instant Interrupts Processor.
DT's Instant Interrupt Processor handles many things, including as you state multiple interrupts, but it also checks for and handles
Register Context saving for you. All of this takes instruction cycles to perform, ~91 instructions.

Also, the PIC MCU's Timer Interrupt is not instantaneous.
There is Interrupt Latency to contend with as well, which a good explanation can be found here in Microchip's Tech Bulletin TB3100.
http://ww1.microchip.com/downloads/c...s/cn566554.pdf

While Timer1 is enabled, the Timer1 Counter increments for each instruction cycle even after an overflow of the counter occurs.
This is a good thing and is exploited by DT to keep track of all of the processing I mentioned above until the Instant Interrupt Processor vectors to the ISR and the "ADD2_TIMER" macro is called and the "BCF T1CON,TMR1ON" statement is executed which turns off Timer1.

By "adding" the TimerConst to the value of Timer1's Counter, the time-based interrupt period is maintained as consistently as possible.

Hopefully this helps.

Secondly, if you are using DT's Instant Interrupts, why wouldn't you use a different label to vector to, for the PORTB.0 Interrupt on Change?
Is there a reason you would put it all in a single ISR handler?
Instant Interrupts should allow you to define multiple sources each with its own Label to jump to when the interrupt occurs.

Just curious.