There is such a feature. Within an interrupt, interrupts are blocked. So read the counter value into a 16 bit global variable while in the interrupt, and exit.
I think some nest by re-enabling higher-priority interrupts in the ISR. I am only using the one ISR anyway.
The interrupt problem: Suppose both interrupt code and non-interrupt code were to read TCNT1 in C, or suppose one reads TCNT1 and the other reads UBRR1, UBRR0, OCR3B, OCR3A, ICR3, TCNT3, OCR1B, OCR1A, ICR1, or EEAR . (Not all of the processors have all of those registers, but if they do, the
bug feature could supposedly occur.)
Alternatively, you can disable interrupts while the main program reads a 16 bit variable. But that doesn't work for timers and some other devices (like the ADC), because they keep running during the two 8-bit operations. It is for this reason that Atmel introduced the above discussed temporary register.
temporarily disabling interrupts does hold off the interrupts, which would allow the two reads to be effectively atomic.
My workaround is to get rid of all references to TCNT1H in my C code.
Is there a place in the Arduino Forum where they would actually like to hear about this, which I consider a tool set bug in implementing the architecture? Semantically it may be a library bug rather than a compiler bug, but somewhere in tool set, this is what I would consider a bug. One for-sure bug would be that any read access to TCNT1H must be immediately be preceded by an an access to TCNT1L. This would apply to any of the 16-bit registers. There is a similar consideration for writes to the low bytes. The not-a-bug portion would be to make the two accesses automatically atomic. Maybe generate a warning? Harder problem because the atomic actions hurts performance much more than an always-needed dummy read or dummy write.