Is this a valid and correct skeleton class/struct
It is kind of hard to tell what you're really asking. Without knowing what you're asking, it's hard to provide a helpful and meaningful answer. I will try regardless. Feel free to point me in the right direction if I'm missing the point.




  Is it valid to refer to class as regular/semiregular/fully ordered?


While I'm not familiar with the terminology, the distinctions are useful. These classifications let you reason about a class. For example, std::list&lt;T&gt;::sort() requires that operator&lt; is defined for T. This is part of what Java and C# interfaces and the suggested C++ concepts feature is about. Note that they aren't necessarily accumulative: A type can be "fully ordered" without being "semi-regular".

However, I can't see a good reason for sorting types into only these categories. Stepanov may have some deeper insight here.




  Are there strong reasons for non-member friend/non-friend member functions?


Like Scott Meyers points out in the article you link to, non-member non-friendfunctions improve encapsulation, which leads to looser coupling. (Looser coupling in turn leads to better complexity handling, replaceable components, more testable interfaces and so on. These are good things.)

Regarding non-member friend functions, I personally consider them a code smell. It doesn't necessarily mean that the code is dirty, but in most cases you don't want friends. (Even without friends, you can still throw party;!) Declaring a friend breaks encapsulation and leads to tighter coupling, which is the opposite of what we want.

(If you do have friends, make sure they interact with an interface (i.e. member function) and not directly with private variables/implementation details.)




  Should friend requirements define member/non-member functions?


I am reading the question as: "Should functions that need to be declared friend be member functions instead?"

For functions that are not part of the class' public interface, the answer is yes, definitely. They should be private member functions.

For functions that are part of the public interface: Unless you have a specific reason to make that function non-member, it should be a member function. The point Scott Meyers is making, however, is this: If the function can use the class' public interface instead of being non-member friend or a member function, it should do so: It should be a non-member, non-friend function that interacts with the type through the type's public interface.

My basic guideline is this: Can the function make use of only the public interface? Then make it non-member, non-friend. If not, make it a member function. However, don't extend the public interface more than otherwise necessary just to allow a function to be non-member, non-friend. If you have to extend the public interface for just a single function, then that function should probably be a member function instead.




  Is it a good rule that each of these groups are implemented fully if at least one member of that group is?


When defining one of assignment operator, destructor or copy constructor, the Rule of Three comes into play and you should probably define the others.

For the categories Stepanov talks about: Yes, if you implement one part of the groups of operators, you should probably implement the others. This is because you should follow the Principle of Least Astonishment. Users of a type expect that if you can say a == b, then you should be able to say a != b as well.

The exception is what he refers to as regular: A type that is constructable may not need to be copyable or movable.