Most, if not all, operations that solicit a writeConcern option have the following logic in their constructor to disregard the write concern if it is the default:

if (isset($options['writeConcern']) && $options['writeConcern']->isDefault()) {
    unset($options['writeConcern']);
}

Consider a case where the Client or Manager is constructed with an explicit write concern (e.g. w:"majority" or w:0) and the Database or Collection overrides it with a default write concern. In this case, the default write concern might get passed on to the operation and become unset, which may result in libmongoc applying the client-level write concern (same as our Client/Manager). I believe the expected behavior for the user would be for the command to either specify the default write concern or none at all, but certainly not the client-level write concern which was overridden.

The logic for detecting and unsetting a "default" write concern goes back to PHPLIB-261 and was implemented to avoid sending empty writeConcern documents in outgoing commands. Although PHPLIB-261 pre-dated MongoDB 4.4 and the notion of a global default write concern, changing that behavior could have implications for whether or not the server-side default might be used. This should be researched and verified before taking any action on this issue.