MongoDb only allow one text index by collection, in contrast of other index types.

This is a limitation that makes it difficult to develop projects with search functionality, for example, if you want to add a text search for advanced users on all fields and a public search on a subset of fields, there isn't a simple and performant way to solve it.

Many developers end up using other products like elastic search, or creating additional collections and using lookup, or using preg_reg or building smart indexes when the creation of multiple text indexes per collection would allow a quick, easy, and efficient solution for many of these scenarios.
 
This would be a good feature for mongodb :)

We recently had an issue where an index did not get created on all shards. When we ran getIndexes() on mongos it reported the index was present. So we dropped another redundant index thinking all would be well - it was not. We had serious performance issues on the shard that was missing the new index and our app was unavailable for a few hours whilst we re-created the missing index on a huge collection.

It would be better if getIndexes called on mongos reported some sort of warning or indication that it was not present on all shards. The same should also be clear on mongo cloud's index view. Even better would be some guarantees that an index will get distributed to all shards, even if there is a transient problem with one of the shards.

Posting this idea at the request of one of the Jira users. You can find more technical details about this in the Jira issue:

https://jira.mongodb.org/browse/SERVER-61613

The gist of it is that I may have two collections, b2 and b3, that are not distinguishable in the Mongo Shell, like this:

db.b2.find()

[

  { _id: 1, created: ISODate("2021-11-18T23:16:33.149Z") },

  { _id: 2, created: ISODate("2021-11-18T23:16:33.149Z") }

] 

db.b3.find()

[

  { _id: 1, created: ISODate("2021-11-18T22:53:02.113Z") },

  { _id: 2, created: ISODate("2021-11-18T22:53:02.113Z") }

] ```

When I merge each into a collection `pg` with this syntax:

db.pg.aggregate([{$merge: {into: "b3", whenMatched: "merge", whenNotMatched: "fail"}} ]);
```

, it reports a cryptic message:

MongoServerError: $merge failed to update the matching document, did you attempt to modify the id or the shard key? :: caused by :: Performing an update on the path 'id' would modify the immutable field '_id '

The pg collection is just an example that in real life is a an aggregation stage before $merge.

The underlying issue is that b2._id is BSON int and b3._id is BSON double, which is not visible in Mongo Shell, and that Mongo DB server fails to recognize numeric types that would work just fine in other comparisons, like queries.

Please report an error or a warning that _id fields in merged collections are of different numeric types, so it would be clear what the problem is, which will save people a lot of time trying to figure out why the type of _id is being changed.

Given that _id is immutable, people would have to drop the collection and recreate it, which may be quite tricky for large databases. If there was a tool to do that or if the server would recognize compatible numeric values and report the error only when numeric types cannot be coalesced, it would also be helpful.