The isMaster response includes topologyVersion: {processId: <objectID>, counter: <long>}. The processId is constant for the process's lifetime. The counter increments on significant topology changes such as stepdown, stepup, reconfig, featureCompatibilityVersion change, or anything else that changes the isMaster response.

This isMaster command accepts two new fields topologyVersion (same type as above) and maxAwaitTimeMS. When these fields are supplied, the isMaster command waits up to maxAwaitTimeMS for the server's topologyVersion to exceed the client's requested topologyVersion. I'm not certain we should document these fields, since they are only expected to be used by mongos and drivers.