Conceptually, this is best solved by having an ISR which always reads the high rate sensor, but implements a toggle so that it only ready the low rate sensor every other execution. On the times when you don't read it you could repeat a stored version of the last reading, though it would be more bandwidth efficient not to transmit that at all.
However, practically speaking this may not be the best choice. The process of reading sensors often has a latency - typically to achieve the highest possible rate you would need to start the reading, and claim the result sometime later. If your two sensors have distinct interfaces, or even if the they share an I2C or SPI bus, you may be able to start readings for both and then claim them with subsequent transactions after allowing them an overlapped measurement time.
It is also not clear that you are best to use an interrupt service routine at all. If your MCU has nothing else to do, the most deterministic and ultimately fastest behavior on an ATmega might be to accomplish reading and direct (unbuffered) serial transmission within the main program loop, busy waiting at each phase. This avoids not only the overhead of context switches when entering an ISR, but also a lot of the variability. That would be doubly true if you can be transmitting the old reading while waiting for the already-triggered sensors to measure the next one.
However, you mentioned you are using a Teensy 3.x, which probably communicates natively via USB, rather than a serial UART. That complicates things a bit - so called "serial" output flows in response to interrupts from the USB engine responding to the host, which is not really deterministic for you. Fortunately, the Teensy is enough faster that you are less likely to have issues with running out of time, particularly when sampling at 100 Hz.