It sounds a little like you may have fallen into the trap of confusing the meaning of what it is that an interface is conceptually as both an implementation (the interface - lowercase 'i'), and an abstraction (An Interface - uppercase 'I').

With regards to your examples, your first bit of code is merely a class. While your class has an interface in the sense that it provides methods to enable accesses to it's behavior, it isn't an Interface in the sense of an Interface declaration that provides a layer of abstraction representing a type of behavior that you may want classes to implement. Doc Brown's answer to your post shows you exactly what I am talking about here.

Interfaces are often touted as the "work-around" for languages that don't support multiple inheritance, but I feel that is more of a misconception than a hard truth (and I suspect I may get flamed for stating that!). Interfaces really have nothing to do with multiple inheritance in that they do not require either being inherited, or being an ancestor in order to provide functional compatibility between classes, or implementation abstraction for classes. In fact, they can allow you to effectively do away with inheritance entirely should you wish to implement your code in that way - not that I'd entirely recommend it, but I'm just saying you could do it. So the reality is that regardless of matters of inheritance, Interfaces provide a means by which class-types may be defined, establishing the rules which determine how objects may communicate with each other, thus they allow you to determine the behavior your classes should support without dictating the specific method used to implement that behavior.

Do I stand to lose anything by allowing (e.g. protected) non-virtual functions to exist within an "interface" in C++? (My feeling is the exactly the opposite - a more natural location for shared code)

A pure Interface is meant to be entirely abstract, because it allows the definition a contract of compatibility between classes which may not necessarily have inherited their behavior from a common ancestor. When implemented, you want to make a choice about whether to allow the implementation behavior to be extended in a subclass. If your methods are not virtual, you lose the ability to extend that behavior later should you decide you need create descendant classes. Regardless of whether the implementation is virtual or not, the Interface defines behavioral compatibility in and of itself, while the class provides the implementation of that behavior for the instances that the class represents.

Is the term "interface" meaningful in C++ - does it imply only pure virtual or would it be fair to call C++ classes with no member variables an interface still?

Forgive me, but it's been a long time since I really wrote a serious application in C++. I do recall that Interface is a keyword for the purposes of abstraction as I have described them here. I would not call C++ classes of any sort an Interface, I would instead say the class have an interface within the meanings that I have outlined above. In that sense the term IS meaningful, but that really depends on the context.

It sounds a little like you may have fallen into the trap of confusing the meaning of what it is that an interface is conceptually as both an implementation (the interface - lowercase 'i'), and an abstraction (An Interface - uppercase 'I').

With regards to your examples, your first bit of code is merely a class. While your class has an interface in the sense that it provides methods to enable accesses to it's behavior, it isn't an Interface in the sense of an Interface declaration that provides a layer of abstraction representing a type of behavior that you may want classes to implement. Doc Brown's answer to your post shows you exactly what I am talking about here.

Interfaces are often touted as the "work-around" for languages that don't support multiple inheritance, but I feel that is more of a misconception than a hard truth (and I suspect I may get flamed for stating that!). Interfaces really have nothing to do with multiple inheritance in that they do not require either being inherited, or being an ancestor in order to provide functional compatibility between classes, or implementation abstraction for classes. In fact, they can allow you to effectively do away with inheritance entirely should you wish to implement your code in that way - not that I'd entirely recommend it, but I'm just saying you could do it. So the reality is that regardless of matters of inheritance, Interfaces provide a means by which class-types may be defined, establishing the rules which determine how objects may communicate with each other, thus they allow you to determine the behavior your classes should support without dictating the specific method used to implement that behavior.

Do I stand to lose anything by allowing (e.g. protected) non-virtual functions to exist within an "interface" in C++? (My feeling is the exactly the opposite - a more natural location for shared code)

A pure Interface is meant to be entirely abstract, because it allows the definition a contract of compatibility between classes which may not necessarily have inherited their behavior from a common ancestor. When implemented, you want to make a choice about whether to allow the implementation behavior to be extended in a subclass. If your methods are not virtual, you lose the ability to extend that behavior later should you decide you need create descendant classes. Regardless of whether the implementation is virtual or not, the Interface defines behavioral compatibility in and of itself, while the class provides the implementation of that behavior for the instances that the class represents.

Is the term "interface" meaningful in C++ - does it imply only pure virtual or would it be fair to call C++ classes with no member variables an interface still?

Forgive me, but it's been a long time since I really wrote a serious application in C++. I do recall that Interface is a keyword for the purposes of abstraction as I have described them here. I would not call C++ classes of any sort an Interface, I would instead say the class have an interface within the meanings that I have outlined above. In that sense the term IS meaningful, but that really depends on the context.