Validators cannot collude to raise proposal rewards, because validators do not have the ability to make invalid blocks. Users would automatically reject the invalid blocks, so from the protocol’s point of view it would be equivalent to them publishing nothing at all.
perform double spend attacks?
Today, not much. But this is exactly why I have proposed A model for cumulative committee-based finality
The only thing that 50%+ of validators could do without being penalized automatically is censor. And for that, community-coordinated soft forks may indeed be the only option.
Again, I think the same applies to a content consensus solution and that this will hugely benefit the security of Ethereum.
The difference between validity and transaction inclusion is that we don’t have consensus on when transactions were published in the mempool, and therefore can’t have consensus on whether or not the transactions were published “on time”. There’s an inherently large gray area. One of the big benefits of blocks instead of transactions as the main unit of analysis is that there is normally only one block per slot, and so the gray area becomes much smaller, and attempting to figure out to what degree a chain is censoring becomes much more computationally tractable.