Currently the IndexBoundsBuilder enforces the property that we never generate a covered plan which will return collator-generated index keys to the user. It does this by returning a tightness of INEXACT_FETCH for any predicate which translates to string bounds over an index with a non-null collator. The consequence is that the access planner will affix such predicates as a filter to the FETCH stage. However, passing the documents through this additional filter is not necessary, since the bounds are logically EXACT.

For instance, suppose that we have an index {a: 1} with a mock collation whose comparison keys are the reverse of the indexed strings. If we insert {a: 'foo'} into the collection, this will generate index key {'': 'oof'}. The current planner implementation will generate a plan that scans the bounds ['oof', 'oof'], fetches the corresponding document, and then filters again by the predicate {a: 'foo'}. Although the FETCH is necessary to recover the original string, the filter is not needed. The bounds ['oof', 'oof'] recover exactly the set of documents that match according to the collation!