W+R > N ensures that a read would encounter at least one write from the last successful write. This is a necessary but not sufficient foundation.

Paxos and Cassandra and others are built on top of this foundation; specifically a majority read/write quorum (a specific instance of W+R > N)

You can think of Basic Paxos as a key value store with a single key (what the literature calls as a "register". We can use the register's name as a notional key). Basic Paxos gives you a wait-free, write once, key-value store with a single key. Once that key has been written to (with the value chosen from among competing proposals), the value is frozen. We have achieved consensus. Abstractly, you can have a mutable store by using a <register name, version number> as a key, so you get an infinity of registers. This is essentially multipaxos, where each cell of the log is a basic paxos register.

Cassandra is a mutable KV store that overrides previous values.

That is the first difference.

Next, it is not sufficient to say "W+R>N" or "quorum majority". Consider:

1. Client C1 writes value A to servers 1 and 2 (server 3 is unavailable)
2. Client C2 writes value B to servers 2 and 3
3. Now server 2 dies, but 1 and 3 are up.
4. Client C3 reads A from server 1, and B from server 3.

How does C3 resolve the tie? It needs some meta data to say which one is a later write.

Cassandra resolves this by attaching a timestamp and says "last writer wins". But no two clocks are synchronized perfectly for ever. It is very possible that C1's write of A had a timestamp (say) of 100, and C2's write, although happening later, has a timestamp of 10, because C2's clock is running slow. C3 will thus infer "A" as the later write. This is wrong. Cassandra will lose updates in such a scenario.

To get a linearizable store -- whether write-once Paxos style, or a linearizable mutable key value store (S3, for example), it is necessary to ensure that the metadata associated with the value be monotonically increasing, so that a later write has a later value. Paxos and others ensure this by using increasing version numbers (called ballots in the paxos paper). Before they can read and return a value, a server will query the others and use the biggest version number, and the value associated with that version number. Since the max version number is always increasing, everyone can agree on the value associated with the highest version.