There are change streams tests that assume getMore will see previous writes, performed after the cursor is established. For example, this assertion in lookup_post_image.js expects to see a delete performed, but this is not a valid assertion. This suite loads jstests/libs/override_methods/set_read_and_write_concerns.js, so the delete was performed with write concern level "majority", and the cursor was established with read concern level "majority" - but this is not enough to be certain the read can see the write when targeted to a secondary. There are two problems here:

First, the write concern of "majority" will ensure the write is applied to the oplog of the secondary, but will not necessarily wait for it to become part of the majority-committed snapshot on the secondary.

Second, the read concern is only enforced at the time of cursor establishment and any subsequent getMore will not wait for read concern. One idea of how to fix problems like this is to turn on causal consistency, but that wouldn't work for cases like this because of this read concern behavior. A readConcern 'afterClusterTime' would/should not be sent with a getMore, so there's no way to force the getMore to wait until the previous write was visible. This does not affect this particular assertion, since it is inspecting the result of an update lookup which issues a separate query with its own read concern to do the lookup, but this could be an issue elsewhere in this suite.