I see your idea. Have to have a think about it and whether worth the extra...
You may be pleased to know that removing that redundant zero statement did make a significant improvement Much improved "cyclic consistency" on timer values. What I found was that the flextimer counter value now decreased more slowly for every reading (at one second intervals) and "wrapped around under zero" to get back to 47,999. It took approx 65 seconds to complete a "value cycle". This decrease is because the flextimer system clock is not perfect (slightly under 48 MHz).
This prompted me to recall a previous debate (see post
https://forum.pjrc.com/threads/28098-Crystal-pull-range-on-3-1?highlight=MHz+crystal). By altering the OSC0_CR register controlling the 16 MHz crystal oscillator (to OSC0_CR = 0x02) I then found that "wrap around under zero" slowed down even further to take 197 seconds for a complete value cycle.
Previous work showed for default OSC0_CR = 0x0A, crystal freq measured 15,999,762 Hz, and for OSC0_CR = 0x02 measured 15,999,922 Hz (much better only 78 Hz slow). This affects the flextimer by a factor of 3, so now my flex system clock is predicted 3 times 78 Hz = 234 Hz under the perfect value of 48,000,000 Hz. It is losing 234 "ticks" every second (compared to perfect), and this takes 48,000,000 divided by 234 = 205128 cycles to recover. With 1000 wrap-around cycles happening per second, this predicts 205 seconds for counter value to complete its value cycle. I think this is close enough to the 197 seconds actual observed to be believable.
What I'm now wondering is... "Could this be an easy method for any Teensy user to measure their own specific 16 MHz crystal frequency precisely?" - just by timing the time in seconds it takes for a flextimer to complete a full "value cycle"? I have the benefit of a Ruby standard, but would this method work without it? Sounds too good to be true
!!