I tried to solve this issue myself, and figured out that it is not so simple. It is possible to make tee() nor crashing, but it is not possible to guarantee the order of the output without using a lock in tee(). It you can get a sequence 1, 2, 4, 3, ...

So we have the following options:

1. Document that the tee() iterator can not be consumed from different threads, even if an underlying iterator is thread-safe.
2. Detect the race condition and raise a RuntimeError (as for iterating modifying dicts).
3. Fix a crash, but document that the tee() iterator can return items out of order if consumed from different threads (PR 9254 basically does this). And exceptions can be raised out of order too.
4. Add a non-reentrant lock in the tee() object and raise a RuntimeError if it is re-entered.
5. Add a reentrant lock in the tee() object.

We can apply different solutions in developed and maintained versions. I would not backport options with locks.