I haven't tried 2.6, but I have looked at the libraries. They are the same in the I2C area. They have another issue as well that I have mentioned before.
Many devices require you to turn on clock stretching (DEFINE I2C_HOLD 1). This is so they have enough time to process whatever you send to them. The slave holds SCL low until it is ready to accept the next byte. The master waits until the SCL goes high and sends the byte. But PBP has no timeout. If a device holds SCL low forever, your program is hung - forever. A similar situation exists if the I2C device is powered from a different power supply than the PIC master. If the slave has no power, it holds SCL and SDA low. I2CWRITE sends (or tries to send) data to the slave and waits for the SCL to go high, which it won't. Result = dead system. The work-around is to ALWAYS check for SCL and SDA to be high before any I2C read or write.

And if you are serious about not using DT-INTs extensively, you should. Yes, you can still do things the old fashioned way of saving/restoring registers, but Darrel has done all the hard work for you. You can use both ASM and PBP interrupts. My 'template' for all new code has the DT-INTs framework. I generally have an ASM interrupt on TMR0 that runs at a 1mS rate. If I need to make certain
I don't miss a pushbutton or some other input, I just put it in the ISR. I can 'latch' the input there and check for it in my main program loop. If I have to respond to something quick, I put the response in the ISR. All the while, I increment a var called MasterClock. I can measure time in ms between any two events. I also use it to time my main loops. For example: You can only read an I2C temperature sensor every 200-300 milliseconds. You can run your main loop as fast as you want, but when MasterClock > 300 you read the sensor, clear MasterClock and keep going. I generally don't use PAUSE at all, and my little PIC responds instantly to all important inputs.