The bulk API executes legacy operations through this fucntion, which does not apply a write concern (w:1 will be applied by default).

The full write concern is only applied (i.e. resetError follwed by a GLE) after all legacy operations have executed, here. The decision for applying a write concern at this point is when the user-provided WC is more than w:1 or w:0 and we haven't seen any write errors or we're unordered and have less write errors than the total number of operations.

As-is, the code is optimized for communication with a standalone server or replica set, as punting the WC to the very end avoids throttling of each legacy operation; however, if we're connected to mongos, the final WC may not be sufficient unless it was blasted to all shards (or at least all those involved in previous writes), which I don't believe is the case.