If a request to build an index is delivered to the server, but that index already exists, the expected behavior is for the server to indicate to the client that the index already exists rather than building a duplicate index:

> db.c.drop()
true
> db.c.createIndex({a: 1}, {name: "index1"})
{
	"createdCollectionAutomatically" : true,
	"numIndexesBefore" : 1,
	"numIndexesAfter" : 2,
	"ok" : 1
}
> db.c.createIndex({a: 1}, {name: "index2"})
{
	"createdCollectionAutomatically" : false,
	"numIndexesBefore" : 2,
	"numIndexesAfter" : 2,
	"note" : "all indexes already exist",
	"ok" : 1
}

Note that the number of indexes before and after are reported as the same in the second invocation of the createIndex command. This is true when the indexes are semantically equivalent (i.e. have the same key pattern and the same collation) even if they are named differently.

This rule is broken if the equivalent index key patterns are "spelled" differently:

> db.c.drop()
true
> db.c.createIndex({a: 1}, {name: "index1"})
{
	"createdCollectionAutomatically" : true,
	"numIndexesBefore" : 1,
	"numIndexesAfter" : 2,
	"ok" : 1
}
> db.c.createIndex({a: 2}, {name: "index2"})
{
	"createdCollectionAutomatically" : false,
	"numIndexesBefore" : 2,
	"numIndexesAfter" : 3,
	"ok" : 1
}

This time, numIndexesAfter > numIndexesBefore for the second index build request. The server currently accepts any positive number to indicate that a field should be indexed ascending and any negative number to indicate that a field should be indexed descending, but these different spellings are not normalized properly.