When a background index build op comes down the replication op stream, the op-application thread spawns a new thread and lets it run. We depend on being able to detect that the bg index build is running for proper operation of other commands that may be subsequently applied by the replication system (such as drop collection).
There is a race between when the thread is created and when the thread first becomes detectable as a bg index build by other commands. We need this to be synchronous (or come up with a new design).
In order to hit this bug, you would need to run one of the index-affecting commands immediately after a background index build completed on a primary. The effect might be that you would get a collection on the secondary that didn't exist on the primary, or that a collection would not have an index on the secondary that did on the primary.