I have one main input pin which needs to wake up the unit

so what you are saying is that if it is NOT that pin when it comes out of SLEEP then by elimination it must be the ULPWU pin?
Yes. Assuming you don't have anything else enabled that could cause the wake up from
sleep.

so then i would check the state of that pin, i.e. there is no bit that says which specific pin caused the wake up ? (i know there is not for the ULPWU)
Yes.

also sorry if i am being dense here but can you explain the mismatch deal some more?
Sure. Say you have GPIO.1 configured for wake up. It's normally held high.

When a switch or other external device pulls this pin low, you want the PIC to wake up.
Wait for GPIO.1 to go high (by reading the port pin). Normally it will be held high by an
external or internal pull-up.

Once it's in the high state, enable wake up on change, then put the PIC to sleep.

Once it goes low, there's a mismatch, and it wakes up. Wait for the pin to return high, and
go through the process again. If the PIC enters sleep mode again, before the port pin was
returned high, then it will wake up again once the pin returns high.

so if i read or write to *any* pin it will clear that mismatch?
Yep. As long as it's a pin on that port, but I normally read the whole port into a variable,
then test for the bit in question.

Testing several bits in a row leaves too much time for another one to change.