For a sharded collection, a call to .getIndexes() or querying the system.indexes collection with a namespace specified (those are equivalent) on a mongos will be directed to the first shard that has chunks of that collection, NOT to the primary shard. This is due to a deliberate hack, see:
https://github.com/mongodb/mongo/blob/1b2af152b9806b0b3443bd4facddf87c8adecb0e/src/mongo/s/strategy.cpp#L95

However, this hack is being circumvented if a read preference is set on the query or if the query has an additional sort. (Other conditions may trigger the same behavior as well, those are the ones we have found so far).

This seems to be a bug in the kernel, as the read preference has nothing to do with what shard is being selected.

In particular, some drivers (Node.js for example) always set a default read preference of primary, therefore circumventing the "hack" and reading the indexes always from the primary shard, not from the first chunk-containing shard.

This is especially problematic if an index is created through mongos where the collection has no chunks on the primary shard (due to tagging for example). The index is then not visible when queried with read preference.

jstests to reproduce behavior (two variants) attached.