The server should not accept (at initiate or reconfig) replica set configs that specify a value for getLastErrorDefaults.w which is greater than the number of data bearing members, eg:

{
    "_id" : "replset",
    "version" : 1,
    "members" : [
        {
            "_id" : 0,
            "host" : "localhost:27017",
            "priority" : 1
        }
    ],
    "settings" : {
        "getLastErrorDefaults" : {
            "w" : 2
        }
    }
}

This is because such configs are self-contradictory — they specify a replica set which cannot acknowledge "plain" (no write concern) writes. Unless they happen to explicitly specify a sensible w value, ordinary write ops/GLE will appear to mysteriously hang. This includes very simple things like "db.foo.insert({})" and mongorestore/mongoimport.

The desired behaviour is that a replSetInitiate or replSetReconfig command with such a config should result in an error like the following (ala SERVER-13055):

{
    "ok" : 0,
    "errmsg" : "Default write concern mode cannot wait for more than the number of data bearers",
    "code" : 103
}

Note that this ticket is NOT asking to forbid a write or getLastError from being able to specify a w value greater than the number of data bearers. Since such operations are independent of the replset config they are not self-contradictory, they are a valid thing for a write to request (irrespective of the set's current ability to satisfy it), and can easily be acknowledged if the replset is suitably reconfig'd.

By contrast, it is non-sensical to declare a replset that has N data bearers and a normal/default write concern of > N. The only way to fix such a situation is to reconfig — highlighting that the config should never have been accepted in the first place.