This came up as a part of the resharding project, as resharding oplog application is subject to write skew. An initial thought was that if the server had a reserve feature that exposed WT's reserve method, we could use this to generate write conflicts and avoid write skew. For now, we have instead implemented functionality that will first read a doc, and then do an unreplicated no-op update on this doc in order to get the desired behavior. After speaking with louis.williams , we think that it's still worthwhile to consider implementing a 'reserve' feature to be used instead because:

1. This code path will be executed for every oplog entry a given resharding recipient applies, and a 'reserve' method would have less of an impact on the WT cache.
2. 'reserve' would not generate oplog entries, and so wouldn't need any extra code to avoid generating oplog entries that we have now