From the read/write concern spec:

Command helper methods for commands that write, other than those discussed above, MAY accept a write concern or write concern options in their parameter list. If the helper accepts a write concern, the driver MUST error if the selected server's MaxWireVersion < 5 and a write concern has explicitly been specified.

Helper methods that apply the write concern inherited from the Collection or Database, SHOULD check whether the selected server's MaxWireVersion >= 5 and if so, include the inherited write concern in the command on the wire. If the selected server's MaxWireVersion < 5, these methods SHOULD silently omit the write concern from the command on the wire.

The specific sentence the C Driver violates is: "If the helper accepts a write concern, the driver MUST error if the selected server's MaxWireVersion < 5 and a write concern has explicitly been specified."

Most of the commands implement the second paragraph from the spec, but do not error out if one passes the write concern in via the options document. (e.g. collection_aggregate_with_opts). These commands should be changed so that if a writeConcern is passed in and maxWireVersion < 5, the driver will throw an error.

Full list of these helper commands:

• aggregate with $out
• copydb
• create
• createIndexes
• drop
• dropDatabase
• dropIndexes
• mapReduce with $out
• clone
• cloneCollection
• cloneCollectionAsCapped
• collMod
• convertToCapped
• renameCollection

Likewise for readConcern, the spec says:

Only the server’s default ReadConcern is support by MaxWireVersion < 4. When using other readConcernLevels with clients reporting MaxWireVersion < 4, the driver MUST raise an error.

The driver implements this properly for aggregate_with_opts, but only silently fails with count, and does not seem to check at all for collection_find_with_opts.