Gossiping the cluster time for causally consistent client sessions ensures causality for queries but it's not enough to ensure causality for sharded metadata operations.

Scenario:

• One client communicating with 2 routers A and B
• Router A performs shardCollection on db.coll
• Router B receives a query for db.coll, refreshes from the CSRS with nearest read preference and read concern with minimum last known config time
• The CSRS secondary serving the refresh still didn't replicate the config.collections entry for db.coll
• Router B treats db.coll as unsharded collection

At some point, router B will get to know that db.coll is sharded (e.g. after targeting the primary). However, gossiping the configOpTime and the topologyTime to the client would have allowed the second router to be causally consistent when refershing with afterClusterTime >= last known configOpTime.