As discussed on SERVER-53813 (which covers a different but related issue), during an unplanned election we can transiently have two primaries. If a user is interacting with a replica set through multiple mongoses (or multiple driver MongoClient instances), they can end up reading stale data, even when using majority read/write concern and primary read preference, as follows:

1. mongos1 or client1 is aware of the new primary, and performs a majority committed write on it
2. mongos2 or client2 is not yet aware of the new primary, and performs a majority RC + primary read preference read on the old primary, and reads data which does not reflect the new write

With a single mongos/client, electionId is used to differentiate which primary is newer.

This is not a bug, however it would be a nice improvement if we could prevent this issue.