The non-geo trailing fields of a compound "2d" index have special key generation rules which as described in SERVER-21011. In cases where a regular btree index would be multikey, "2d" index key generation results in a single key where the indexed values are stored as a single array (see the example below).

> db.c.drop()
true
> db.c.ensureIndex({a: "2d", "b.c": 1})
{
	"createdCollectionAutomatically" : true,
	"numIndexesBefore" : 1,
	"numIndexesAfter" : 2,
	"ok" : 1
}
> db.c.insert({a: [0, 0], b: [{c: 5}, {c: 6}]})
WriteResult({ "nInserted" : 1 })
> db.c.find().hint({a: "2d", "b.c": 1}).returnKey()
{ "a" : BinData(128,"wAAAAAAAAAA="), "b.c" : [ 5, 6 ] }

As a consequence, the planner will never generate bounds over the trailing fields of a "2d" index, but rather resorts to covered matching. This is enforced in the planning code in the following locations:

https://github.com/mongodb/mongo/blob/r3.3.5/src/mongo/db/query/planner_access.cpp#L325-L340
https://github.com/mongodb/mongo/blob/r3.3.5/src/mongo/db/query/planner_access.cpp#L352-L357

In the case of indices with a collation, however, covered matching is currently not legal. Therefore, there is currently no utility for the user in specifying a collation on a "2d" index, and doing so should result in an error. Once SERVER-21011 is fixed, however, we should be able to safely generate bounds over the trailing fields in many cases.

Once SERVER-21011 is fixed, the work for this ticket is as follows:

• Add "2d" to the whitelist of index types that may accept a collation.
• Update TwoDAccessMethod::getKeys() to convert string elements to their corresponding comparison keys.
• Ensure that string comparisons done by a filter attached to the IXSCAN stage are done in the realm of collator-generated comparison keys. That is, strings inside comparison predicates in the filter must be converted to their corresponding CollatorInterface::ComparisonKey values.