Fixing this is likely to make users happier and avoid bad PR, as incorrect and too strong claims in the docs were part of the motivation for the Call Me Maybe posts about MongoDB.

From http://docs.mongodb.org/master/core/write-concern/
"With replica acknowledged write concern, you can guarantee that the write operation propagates to additional members of the replica set"

That is not guaranteed. The feature provided is that writes are not acknowledged until a majority of the replica set has received the change. But there is no guarantee that the change reaches a majority as the master can fail while waiting for that to happen.

From http://docs.mongodb.org/master/core/replica-set-write-concern/
"Use of insufficient write concern can lead to rollbacks in the case of replica set failover. Always ensure that your operations have specified the required write concern for your application."

There are at least 3 types of rollbacks:
1) committed to master, visible to nobody, not acknowledged
2) committed to master, visible to somebody, not acknowledged
3) committed to master, visible to nobody, acknowledged
4) committed to master, visible to somebody, acknowledged

For #1, we can pretend the commit didn't happen and rollback doesn't matter.

Write concern majority avoids #3 and #4

Write concern majority doesn't prevent #2. Read concern majority in 3.2 will help with that.

From http://docs.mongodb.org/master/applications/replication/
"In MongoDB, clients can see the results of writes before they are made durable:
Regardless of write concern, other clients can see the result of the write operations before the write operation is acknowledged to the issuing client."

This is only true for mmapv1

http://docs.mongodb.org/master/core/replica-set-rollbacks/
"Regardless of write concern, other clients can see the result of the write operations before the write operation is acknowledged to the issuing client."

I forgot the answer. Does WiredTiger release its equivalent of row locks while waiting for secondaries to acknowledge?

From http://docs.mongodb.org/master/reference/write-concern/
"Confirms that write operations have propagated to the majority of voting nodes: a majority of the replica set’s voting members must acknowledge the write operation before it succeeds. This allows you to avoid hard coding assumptions about the size of your replica set into your application."

I would change the first sentence to "Confirms that write operations have propagated to the majority of voting nodes before acknowledging the write". As written the first part of the sentence claims something stronger. I also assume that "reach" means that secondaries have the change in their log, but might not have applied the change. So a read on the secondary after doing the write on the master might not see the change.