We had to make two downstream-facing changes to how writeconcern arguments are parsed:
1) The writeconcern argument to a command is a document; previously, this document could contain a field whose fieldname was any capitalization variant of "getLastError" (the value of this field was ignored). Now, we'll still parse writeconcern documents that contain a "getLastError" field (and ignore the value), but only with the capitalization "getLastError." So previously we'd parse both:
a) {..., writeConcern: {w: 1, ..., getLastError: foo}}
and
b) {...,writeConcern: {w: 1, ...,GetlastError: foo}}
without error. But now, we'll only parse (a), and (b) will fail to parse.

Note that the "getLastError" field in a writeconcern argument is deprecated, and has been ignored for as long as we can look back/remember (so ideally, nothing downstream should be using it anyway). Additionally, the writeconcern argument will still parse correctly with "wOpTime" or "wElectionId" fields present, though these options are also deprecated and their values are ignored, both before and after these changes. (To avoid confusion: these fields are accepted only when capitalized as spelled in the previous sentence, both before and after these changes; the getLastError behavior was unique).

2) Previously, when we couldn't parse a writeconcern, we'd return a response to the client with a generic error code corresponding to some general error, like ErrorCodes::FailedToParse. Now, we'll return a unique error code, that doesn't have some general meaning.

Thanks!