Multi-Byte Receive Issues with MSP430F5529 USCI I2C

I have been working on setting up communication between an MSP430F5529 I2C Master and several peripheral slaves.  I've encountered some difficulty terminating multi-byte receives at higher clock speeds.  Below is the ISR I have been using from the MSP430F55xx C Samples provided by TI:

//-------------------------------------------------------------------------------
// The USCI_B0 data ISR is used to move received data from the I2C slave
// to the MSP430 memory. It is structured such that it can be used to receive
// any 2+ number of bytes by pre-loading RXByteCtr with the byte count.
//-------------------------------------------------------------------------------
#pragma vector = USCI_B0_VECTOR
__interrupt void USCI_B0_ISR(void)
{
switch(__even_in_range(UCB0IV,12))
{
case 0: break; // Vector 0: No interrupts
case 2: break; // Vector 2: ALIFG
case 4: // Vector 4: NACKIFG
  UCBOCTL1 |= UCTXSTP;
  UCB0STAT &= ~UCNACKIFG
  break;
case 6: break; // Vector 6: STTIFG
case 8: break; // Vector 8: STPIFG
case 10: // Vector 10: RXIFG
  RXByteCtr--; // Decrement RX byte counter
  if (RXByteCtr)
  {
    *PRxData++ = UCB0RXBUF; // Move RX data to address PRxData //CASE 1
    if (RXByteCtr == 1) // Only one byte left?
    UCB0CTL1 |= UCTXSTP; // Generate I2C stop condition
    //*PRxData++ = UCB0RXBUF; // Move RX data to address PRxData //CASE2
  } 
  else
  {
    *PRxData = UCB0RXBUF; // Move final RX data to PRxData
    //__bic_SR_register_on_exit(LPM0_bits); // Exit active CPU
  }
  break;
case 12: break; // Vector 12: TXIFG
default: break;
}

Note that I have removed the call to exit LPM0.  For debugging purposes I instead idle inside of a while( UCB0STAT & UCBBUSY) to verify that the transaction has truly finished.  I may return to making use of the LPM once this is working.  For clarity, it may be worth mentioning that RXByteCtr is initially set to the number of bytes I wish to receive, so handling the final byte will begin by decrementing RXByteCtr from 1 to 0.  Anyways, on to the problem.

At low bus speeds (60 kHz) everything works.  At higher bus speeds (>100kHz) I observe the following, even when communicating with another MSP430F5529 set in slave mode which should be capable of much faster speeds: 

CASE 1: When UCTXSTP is set AFTER reading the 2nd to last byte. Normally everything works, but occasionally I will observe 1 extra bytes on the bus, and the would-be final byte will NOT be transferred into PRxData.  EDIT I have also verified that the ISR is NOT getting called an extra time to account for the extra byte.  This is important, as it eliminates one very easy explanation to why the would-be-final byte was not showing up in PRxData. /EDIT

CASE 2: When UCTXSTP is set BEFORE reading the 2nd to last byte.  Normally everything works, but occasionally I will observe the correct number of bytes on the bus and yet the 2nd-to-last byte will NOT be transferred into PRxData.

Here is my theory on what is happening:

CASE1: If UCTXSTP gets set BEFORE the UCSI module acks the final byte, everything's dandy.  However, if the USCI module manages to ACK the final byte in-between the MSP reading from UCRXBUF and setting UCTXSTP, then somehow the would-be final byte is lost. Presumably this lost byte gets over-written by the new final byte. 

CASE2: I assume the USCI module will always have begun transmission of the final byte by the time the ISR for the reception of the 2nd-to-final byte begins.  So I suspect that once UCTXSTP gets set, it's a race between the MSP430 reading RXBUF to clear the 2nd-to-last byte and the USCI module finishing reception of the final byte and over-writing the RXBUF before the MSP430 has a chance to read it.

In both cases, the fundamental problem seems to revolve setting UCTXSTP allowing the USCI modle to over-write the UCRXBUF before the msp has a chance to read it.  However, I have not read anything in the user's guide or elsewhere that explicitly confirms this behavior (the user's guide seems a little vague about the specifics of these transactions.  What happens when a stop condition gets set "immediately"?  I believe this is where it might be worth clarifying whether or not the UCRXBUF gets overwritten).

I am looking for a way to circumvent this issue without slowing the bus. 

Any suggestions or clarifications are appreciated, thanks a lot!