Starting a few days ago, C Driver tests against a sharded cluster with standalone (non-replica-set) shards fail. The test is attempting a listCollections command with causal consistency (readConcern afterClusterTime) on the mongos and receives "Cannot specify afterClusterTime readConcern without replication enabled".

Seems to be an unintended consequence of SERVER-33798. The driver sees that mongos includes $clusterTime and operationTime in its command responses and thinks that the deployment supports causal consistency. It obeys the Causal Consistency Spec:

When executing a causally consistent read, the afterClusterTime field MUST be sent when connected to a deployment that supports cluster times, and MUST NOT be sent when connected to a deployment that does not support cluster times.

I've only thought about this for a minute but I think the new error is a breaking change for 3.6-era drivers when they're configured for causal consistency. I propose relaxing the new check implemented in SERVER-33798: standalone shards shouldn't reject readConcern afterClusterTime, since standalones are naturally causally consistent. Alternatively, a mongos that knows of any standalone shards shouldn't advertise operationTime, but that's complicated and racy.