Mongo support have asked me to raise this bug as an improvement idea because they see it as an edge case.
The issue is here and includes more details:

https://support.mongodb.com/case/00659614

In summary, if you have a geoJson sub document that sits within an array, and you index it using the 2dspehere index, you get keys duplicated for every element in the array.

For example, if you have geoJson that represents a big 4,500 vertex polygon, and you put it within an array element, if the array has only one element I see 20 keys generated, which is good. But if you have another element in the array that doesn’t have any geoJson, another 20 keys are generated, now totaling 40 keys for that document.

In our application this bug can cause the index memory requirements for 2dsphere to become a serious concern.

We have stopped using the index and developed an alternative.

Often Views, defined by an aggregation pipeline, are used to filter out certain fields, certain records and obfuscate parts of certain values to enable users with a specific restricted role to only see a subset of 'less sensitive' data from a collection. Views can be assigned to a role declaratively, but in some use cases it is also useful to allow the aggregation pipeline logic to be able to access the context of the current session's roles (e.g. $$ROLES) or user id (e.g. $$USER) to be able to make some programmatic decisions of what to show in the view based on current user & role (i.e. to perform programmatic role based access control).

In some examples, this aggregation pipeline may even want to use $$ROLES or $$USER to then perform a $lookup on a different 'metadata' collection, to influence what it decides to return as the output of the view.

Provide the ability for orgs to update things like large reference data sets periodically. E.g. an ecommerce site updates its product inventory every night at midnight, where even though the inserts or updates may take say 10 minutes to run and complete, the applications do not see the changes until the bulk update finishes. The problem otherwise is currently, the ecommerce app, in this example, may be reading product data partly from yesterday's data and partly from today's changed data, during the 10 minute run. For consistency the application would ideally want to see data from either before the bulk update state or after bulk update state, and not any immediate state.

Note 1: This isn't really a transactions use case as transactions are typically much more ephemeral and short lived
Note 2: If something went wrong part way through the bulk insert/update, there would need to be someway of unwinding all these changes to applications never see them (and once some fixes upstream issues they can do a full run again)
Note 3: I've given ecommerice as an example, but most verticals have these use cases, e.g. changing bulk reference data in FinSvcs.

Election is an expensive operation. We can avoid the elections if we can enforce some priority-based ordering on who shall become primary if the current primary fails.
Specifically, we can keep a node with second highest priority in the data center of the most preferred primary. Usually, the network failures within the data centers are less probable than across the data centers. So, it is reasonable to believe that if the second preferred member loses the contact with current primary, it is the primary node which has failed and not the network. As a supplement, we can also have redundant network connection between the two. So, we do not need to wait for 10 seconds to detect that it is a node failure. Write operations can immediately shift to the second preferred member and this would make system “more” available for writes.

When performing a bulk operation, it is possible to obtain the _ids of upserted documents via BulkWriteResult. For example:

db.getCollection("test").find({})

db.test.drop()

var bulk = db.test.initializeUnorderedBulkOp();
bulk.find({name: "huey"}).upsert().updateOne({name: "huey"});
bulk.execute();
```

The BulkWriteResult contains the upserted _id:

BulkWriteResult({
"writeErrors" : [ ],
"writeConcernErrors" : [ ],
"nInserted" : 0,
"nUpserted" : 1,
"nMatched" : 0,
"nModified" : 0,
"nRemoved" : 0,
"upserted" : [
{
"index" : 0,
"_id" : ObjectId("5ec77b5cc4a955ce03a4cd2e")
}
]
})

However, when a document already exist, the _id is not returned:

db.test.find()

var bulk = db.test.initializeUnorderedBulkOp();
bulk.find({name: "huey"}).upsert().updateOne({name: "huey", outfit: "red"});
bulk.find({name: "luey"}).upsert().updateOne({name: "luey", outfit: "green"});
bulk.find({name: "duey"}).upsert().updateOne({name: "duey", outfit: "blue"});
bulk.execute();

Returns:

BulkWriteResult({
"writeErrors" : [ ],
"writeConcernErrors" : [ ],
"nInserted" : 0,
"nUpserted" : 2,
"nMatched" : 1,
"nModified" : 1,
"nRemoved" : 0,
"upserted" : [
{
"index" : 1,
"id" : ObjectId("5ec77b5cc4a955ce03a4cd39")
},
{
"index" : 2,
"id" : ObjectId("5ec77b5cc4a955ce03a4cd3a")
}
]
})

This forces you to make a subsequent query to retrieve the entries that weren't upserted.

This request is that BulkWriteResult incorporates a list of matched document ids on a bulk upsertOne operation when it turns out that the documents already exist

Currently, there is no way for Database Users to manage their own passwords, (even if they are atlasAdmin@admin). Moreover, as a Project Owner, I cannot create a role that allows them to do so, e.g.:

use admin
db.createRole(
   { role: "changeOwnPasswordRole",
     privileges: [
        {
          resource: { db: "", collection: ""},
          actions: [ "changeOwnPassword"]
        }
     ],
     roles: []
   }
)

As such, changing passwords always requires a Project Owner setting the new password and sharing it with the Database User. This is a problem, because user-password combinations known by more than one person do not serve as proof of identity.

A Database User should, either by default or via a role, have the changeOwnPassword Mongo permission, so they can change their own passwords without having to share them with someone else (i.e. a Project Owner).