Before the introduction of the move constructor and move assignment in C++, I had two clear conceptual categories of classes: values for which using a copy was not different from using the original value, entities for which it was different. For values, I provided the copy constructor and assignment operator (and equality operators), for entities I didn't (if a copying operation made sense, the copy constructor was explicit, and the copy operation was not provided by assignment operator; equality was never a meaningful concept).
Introduction of move introduced a new category, and sadly I seem not to have found out a conceptual criteria which would allow me to do the choice of providing move operations or not for non value classes. Currently, I'm mostly driven by implementation considerations and that leaves me unsatisfied. More, recently I had to make a class evolve and I had to make the choice of either removing the move operations or introduce unwarranted complexity. Luckily, move operations were provided and not used and the choice was thus not too difficult. That event highlighted the fact that I had a conceptual issue.
How to make the choice between non-copyable non-movable types and move-only types without relying on intuition or implementation details?