> C++ does not (or at least did not at the time) have a concept of interfaces. There was a pattern in some development communities for defining interfaces by writing classes that followed particular rules, but no first-class support for them in the language.

Your distinction between "first class support for interfaces" and "C++ support for interfaces" looks like an artificial one to me.

Other than not requiring the keyword "interface", what is it about the C++ way of creating an interface that makes it not "first class support"?

>no first-class support for them in the language.

An interface is just a base class none of whose virtual functions have implementations. C++ has first class support for it. The only thing C++ lacks is the "interface" keyword.

The main reason (other than self-documentation) that some other languages separate interfaces form normal classes is that they only support multiple inheritance for interfaces.

C++ doesn't have this restriction, so interfaces would add very little.

Because multiple inheritance causes the diamond problem. C# forces you to solve it by declaring one method as the "canonical" and the others as "explicit interface implementations" (only accessible if the variable/receiver is typed as that interface).

The diamond problem strictly speaking only has to be one when the common base class has constructor arguments. While a Java-style interface construct makes it easy to prevent, it also imposes much stronger restrictions than the above. It would have been possible to only impose the above restriction. Yes, there are failure cases with separate compilation, but the way Java dynamically loads classes, that would be similar to how when the JVM loads a class file that is supposed to be an interface, it discovers that instead it has been changed to a class.

Java having an explicit ”interface” construct is one thing I didn’t like about it, because it muddles the notion of a class implicitly having an interface (a notion that clearly exists in C and C++, by way of header files if nothing else) with that construct, while on the other hand there is no a-priori reason to have a distinction between Java’s interfaces and pure abstract classes. Both specify an interface to be implemented. And Java 8+ muddles its concept further by allowing default methods and static members.

The important thing is to distinguish between interface and implementation, and that is relevant to any class, whether it implements a separately defined interface or not.

Java (following Objective-C) does need a differentiation between interface and pure abstract class - this is because it is single inheritance - a class can have any one class to inherit from but it can have many interfaces.

That doesn’t follow. The restriction could have been defined in terms of allowing at most one parent class to be non-pure-abstract. And there are lesser restrictions hat would have been conceivable as well. Java is single-inheritance only in the sense of the particular interface–class distinction it makes. For example, since Java 8 you can inherit method implementations from multiple interfaces.

Java's object model is based on Objective-C's so a direct descendant and Objective-C's object model is based on Smalltalk so there is a direct connection there.