There are some pointers to better terminology at the end of the post — e.g. I like Terry's session guarantees (read-your-writes, monotonic reads, etc) — but they too only cover a small subset of the design space.
In the end, this stuff is still evolving, and we simply don't yet know the best way of describing things. I wouldn't want to propose some alternative classification scheme that would be no better than the one it replaces. But I do want to encourage people to be precise and thoughtful with the terminology they use.
I agree with most everything you've said, but until we have good concise descriptions I think it is unfair to really say: "Never use these".
Quick less-precise overviews serve a real purpose and are very helpful to users and decision makers.
I guess my opinion is projects should never ONLY say it is CP or AP, but I think it is perfectly acceptable in your project overview to say: This database is CP*. Then have a longer technical discussion somewhere else where they use more precise and thoughtful language.
I understand and agree with the sentiment, but we humans need fuzzy short overviews. Then again a blog post titled: "All databases need an in-depth technical discussion page" doesn't quite capture the imagination.
In the end, this stuff is still evolving, and we simply don't yet know the best way of describing things. I wouldn't want to propose some alternative classification scheme that would be no better than the one it replaces. But I do want to encourage people to be precise and thoughtful with the terminology they use.