The BSON spec defines arrays as:

Array - The document for an array is a normal BSON document with integer values for the keys, starting with 0 and continuing sequentially. For example, the array ['red', 'blue'] would be encoded as the document {'0': 'red', '1': 'blue'}\. The keys must be in ascending numerical order.

The server enforcement of this specification is a mixed bag. There are four different behaviors that I've observed:

1. When inserting a document with array keys that violate the specification, the server ignores the keys and stores the document. I'm sure there are other situations where the keys are ignored.
2. The bad array keys are ignored, and the server replies with incorrect data (I was able to make this happen with $addToSet, where the $each field contained an array where all the keys were set to "-1").
3. For some commands, the server will detect the bad array keys and uassert, which closes the connection
4. In other (rare, I'm sure) cases, the server will crash. See SERVER-90985.

What's especially unpleasant about the current situation is that an application could insert a document with bad array keys, and then much later, put that array through an aggregation pipeline that performs some operation on the array, and it uasserts. That would be potentially very tricky to track down in a customer escalation.

Note that the drivers specification for BSON requires that BSON generators create BSON arrays that conform to the specification, but also that BSON parsers completely ignore the keys.

Please consider making the server behave consistently regardless of which command is being executed and which array has bad keys. The safest way to do that is to just remove all validation of BSON array keys, as drivers already do.

As a bonus, this could result in a performance improvement for some array-heavy workloads .