Guaranteeing a quorum of nodes will see the updates does not solve the problem because supporting multiple non-primary key columns in the materialized view primary key introduces a sensitivity to the ordering of updates to these non-primary key columns.
I think this is the simplest version of Benedict's example. Envision a cluster with a table with primary key P and columns A and B. Presently, all replicas contain an entry for P=1, A=1, B=1.
Two concurrent updates are occurring - one setting A=2, and one setting B=2. One replica receives the update B=2, removes the MV entry for P=1, A=1, B=1, creates an MV entry for P=1, A=1, B=2, and then crashes with data loss. The remainder of the base replicas receive the update A=2; remove the MV entry for P=1, A=1, B=1; create an MV entry for P=1, A=2, B=1; receive the update B=2; remove the MV entry for P=1, A=2, B=1; and create an MV entry for P=1, A=2, B=2.
Upon repairing the data lost base replica from the remaining base replicas, a delete for the entry P=1, A=1, B=2 in the paired replica will never be created.