This issue was identified by joe.caswell, who observed the following correctness problem after creating a wildcard index:

 > db.c.drop()
true
 > db.c.insert({a: [["test"]]})
WriteResult({ "nInserted" : 1 })
 > db.c.find({"a.0.0": "test"})
{ "_id" : ObjectId("5d40b2c8a1925e90174dbd65"), "a" : [ [ "test" ] ] } // Document matches as expected.
 > db.c.createIndex({"$**": 1})
{
	"createdCollectionAutomatically" : false,
	"numIndexesBefore" : 1,
	"numIndexesAfter" : 2,
	"commitQuorum" : 1,
	"ok" : 1
}
> db.c.find({"a.0.0": "test"})
// Document does not match! This is a bug due to an incorrect plan.

When a wildcard index is present, the planner attempts to use it in order to satisfy the equality predicate over the path "a.0.0". In this example, both "0" path components resolve to array indexes. The access plan, however, does not correctly account for these array index path components. This leads to missing results.

This issue should only impact queries which attempt to match a nested array by using multiple subsequent array indexes. Operations which do not query by array index, or which do not have multiple adjacent array index path components (e.g. "a.0" or "a.0.b.1") are not affected.