This is a behaviour change in MongoDB 5.0 that fixes a bug with some edge case scenarios where order of operations is important when applying updates to a document (for example, when manipulating arrays). The previous behaviour could result in an error message for an update that you would expect to be supported.
Starting in MongoDB 5.0, update operators process document fields with string-based names in lexicographic order. Fields with numeric names are processed in numeric order.
In MongoDB 4.4 and earlier, update operators process all document fields in lexicographic order.
Consider this example $set command:
{ $set: { “a.2”: <new value>, “a.10”: <new value> } }
In MongoDB 5.0 and later, “a.2” is processed before “a.10” because 2 comes before 10 in numeric order.
In MongoDB 4.4 and earlier, “a.10” is processed before “a.2” because 10 comes before 2 in lexicographic order.
We found that the updated array grows correctly except when lexicographic order differs from numeric order. You may still see issues if you try to manipulate a null 9th element with $bit if it was created implicitly when the 10th element was created.
If “a.10” in the update example is processed first, null array values will be implicitly created for all of the preceding elements in the array. This can lead to an error if the same update command then tries to manipulate “a.2” (eg $bit operation on a null value, since $bit is expecting either an empty value or a numeric value).
If “a.2” is processed before “a.10” (in numeric order), the array will grow correctly.