There could be a conflict between afterClusterTime readConcern injected by shell or driver and internal checks if user wants to specify afterOpTime or different readConcern.
The shell code does not overwrite existsing attributes but does not check for invalid combinations either:
https://github.com/mongodb/mongo/blob/r3.5.11/src/mongo/shell/mongo.js#L158-L163

1. A message can not have both afterClusterTime and afterOpTime - it will cause an error.
The check is done here: https://github.com/mongodb/mongo/blob/r3.5.11/src/mongo/db/repl/read_concern_args.cpp#L162-L167
which causes an error at some tests.

2. A message can not have linearizable readConcern:
https://github.com/mongodb/mongo/blob/r3.5.11/src/mongo/db/repl/read_concern_args.cpp#L169-L178
also breaks tests

3. If clusterTime gets to the new unsharded cluster it may hit this error:
https://github.com/mongodb/mongo/blob/r3.5.11/src/mongo/rpc/metadata.cpp#L107-L112