Generally speaking, when a command succeeds but fails waiting for write concern, the command response indicates ok:1, but has a writeConcernError field.

When we made it so all commands that write can accept write concern, we finally standardized on that method of reporting write concern errors. User management commands, however, already supported write concern, and they reported errors differently - a failed write concern for them caused the whole command to report ok:0. In 3.4 we continued to provide that behavior for user management commands to preserve backwards compatibility until drivers were all updated to know to always check for the presence of the writeConcernError field. Now that it's been a full release since we made that change, we should be able to remove this bandaid and have user management commands handle write concern errors the same way as any other command.

The bandaid code exists here, and already has a TODO to remove it.