Here's the features I can imagine being worth major backwards compatibility breaks:
1. Fully pluggable storage with a clean API.
2. Total elimination of VACUUM or XID freezing
3. Fully transparent-to-the user MM replication/clustering or sharding.
4. Perfect partitioning (i.e. transparent to the user, supports keys & joins, supports expressions on partition key, etc.)
5. Transparent upgrade-in-place (i.e. allowing 10.2 to use 10.1's tables without pg_upgrade or other modification).
6. Fully pluggable parser/executor with a good API
That's pretty much it. I can't imagine anything else which would justify imposing a huge upgrade barrier on users. And, I'll point out, that in the above list:
* nobody is currently working on anything in core except #4.
* we don't *know* that any of the above items will require a backwards compatibility break.
People keep talking about "we might want to break compatibility/file format one day". But nobody is working on anything which will and justifies it.
Of your list, I know 2ndQuadrant developers are working on 1, 3, 5.
6 has being discussed recently on list by other hackers.
I'm not really sure what 2 consists of; presumably this means "take the pain away" rather than removal of MVCC, which is the root cause of those secondary effects.
I don't think the current focus on manually intensive DDL partitioning is the right way forwards. I did once; I don't now.
--
Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
