premature TB0CCTL6.CCIFG on TB0 capture after changing TB0 source

I'm continuing to play with DCO calibration on the MSP430F5438A, and ran into the following anomaly:

The MSP430F5438A is configured with its DCO at 8 MiHZ (2^23 Hz) off XT1, which is 32 kiHz.

I configure TB0 to capture an SMCLK-driven counter on falling edges of ACLK, followed by using TB0 to delay for a specific number of ACLK cycles:

    /* Capture the SMCLK ticks between adjacent ACLK ticks */
    TB0CTL = TBSSEL__SMCLK | MC__CONTINOUS | TBCLR;
    TB0CCTL6 = CM_2 | CCIS_1 | CAP | SCS;
#if 0
    /* NOTE: CCIFG seems to be set immediately on the second and
     * subsequent iterations.  Flush the first capture. */
    while (! (TB0CCTL6 & CCIFG)) {
      ; /* nop */
    }
    TB0CCTL6 &= ~CCIFG;
#endif
    while (! (TB0CCTL6 & CCIFG)) {
      ; /* nop */
    }
    c0 = TB0CCR6;
    TB0CCTL6 &= ~CCIFG;
    while (! (TB0CCTL6 & CCIFG)) {
      ; /* nop */
    }
    c1 = TB0CCR6;
    tb0cctl6 = TB0CCTL6;
    TB0CTL = 0;
    TB0CCTL6 = 0;

#if 1
    cd = (c0 > c1) ? (c0 - c1) : (c1 - c0);
    printf("c0=%u c1=%u cd=%u RSEL=%u DCO=%u MOD=%u ; TB0CCTL6=%04x ; will delay %u\n",
       c0, c1, cd,
       (UCSCTL1 >> 4) & 0x07, (UCSCTL0 >> 8) & 0x1F, (UCSCTL0 >> 3) & 0x1F,
       tb0cctl6,
       delay_ctr);
#endif

    /* Delay for 32 ACLK cycles */
    TB0CTL = TBSSEL__ACLK | MC__CONTINOUS | TBCLR;
    TB0CCTL0 = 0;
    TB0CCR0 = TB0R + 32;
    while( ! (TB0CCTL0 & CCIFG ) ) {
      /* nop */
    }
    TB0CTL = 0;
    TB0CCTL0 = 0;

    /* Delay before grabbing frequency again */
    ctr = delay_ctr++;
    while (0 != ctr--) {
      __nop();
    }

If this sequence appears in a loop, TB0CCTL6.CCIFG is set immediately on the second and subsequent iterations, unless there is a delay between clearing TB0 from using ACLK and reconfiguring it to use SMCLK:

Boot TB0CTL 0000 ; TB0CCTL6 0000
c0=123 c1=251 cd=128 RSEL=3 DCO=29 MOD=10 ; TB0CCTL6=9901 ; will delay 1
c0=0 c1=61 cd=61 RSEL=3 DCO=29 MOD=9 ; TB0CCTL6=9901 ; will delay 2
c0=0 c1=61 cd=61 RSEL=3 DCO=29 MOD=9 ; TB0CCTL6=9901 ; will delay 3
c0=0 c1=61 cd=61 RSEL=3 DCO=29 MOD=10 ; TB0CCTL6=9901 ; will delay 4
c0=0 c1=61 cd=61 RSEL=3 DCO=29 MOD=10 ; TB0CCTL6=9901 ; will delay 5
c0=0 c1=60 cd=60 RSEL=3 DCO=29 MOD=9 ; TB0CCTL6=9901 ; will delay 6
c0=0 c1=61 cd=61 RSEL=3 DCO=29 MOD=10 ; TB0CCTL6=9901 ; will delay 7
c0=61 c1=189 cd=128 RSEL=3 DCO=29 MOD=9 ; TB0CCTL6=9901 ; will delay 8
c0=61 c1=189 cd=128 RSEL=3 DCO=29 MOD=10 ; TB0CCTL6=9901 ; will delay 9
c0=61 c1=188 cd=127 RSEL=3 DCO=29 MOD=10 ; TB0CCTL6=9901 ; will delay 10
c0=61 c1=189 cd=128 RSEL=3 DCO=29 MOD=9 ; TB0CCTL6=9901 ; will delay 11

Code in context is attached; though it does depend on a test harness it should be clear how things are initialized.

The problem does not appear if MCLK is decreased to 4 MiHz, but is present at 16 MiHz.  It is present whether or not FLL is disabled after the DCO is configured.

I checked slaz057n and found no relevant TBx errata.  Note that TB is in a halted state (TB0CTL == 0) prior to being configured.

Am I doing something wrong?  Is this an erratum?