On standalones, the explain command does not support readConcern, as it uses the default implementation of supportsReadConcern() (see here). For example

db.c.runCommand({explain: {find: "c", query: {a: 1}}, readConcern: {level: "available"}}) // Error

It is, however, legal to provide a readConcern in the inner command. For example:

db.c.runCommand({explain: {count: "c", query: {a: 1}, readConcern: {level: "available"}}})

When running explain on a sharded cluster, mongos will "hoist" generic options from the inner command into the top-level "explain" command which it sends to the shards. See here). The result of this is that attempting to explain a query with a readConcern other than "local" on mongos throws an error.

It is possible to get different query plans using different readConcern levels, and it would be extremely useful if explain() could reflect this. For example, queries run with readConcern "available" do not perform orphan filtering, and do not need a SHARD_FILTER stage. In many cases, this can lead to a completely different plan being used than if the query had been run with a stronger readConcern.