Current bulk write operations provide only aggregated counts that look like this:

{
acknowledged: true,
insertedCount: 0,
insertedIds: {},
matchedCount: 2,
modifiedCount: 2,
deletedCount: 0,
upsertedCount: 0,
upsertedIds: {}
}

All these operations are processed individually by the server, even if out of order, meaning that the current Mongo DB code aggregates these individual counts in order to present them in the structure above.

This aggregation, however, makes it impossible to use bulk writes in the same way single updates and deletes can be performed, which significantly slows down mass updates.

Consider updates of versioned documents - one can issue 100 updates, where a version is a part of a criteria. If updates would be tracked in the same way inserts/upserts are (with relation to their operation index, not document IDs, which would be an overkill), there would be a dictionary in the bulk result object, with the bulk operation index as a key and the number of matched and modified or deleted document as the value.

This way callers could identify that, say 90 of those 100 versioned updates were successful and 10 were not and then use client-side mapping between those bulk operations in the original structures to infer which ones failed, so the failed document could be reported as needed, such as reporting stale versions, etc.