That's only a problem if you think the terminology matters. It doesn't. What matters are the concepts. It's much easier to map the terminology onto the concepts than to try to go the other way around.
For example, it's much easier to go from a concept like "I can use the SAME NAME for DIFFERENT FUNCTIONS in the SAME PROGRAM, and there are various ways to map useful semantics onto the resulting code" to "If I resolve the ambiguity at run-time then it's POLYMORPHISM and if I do it at compile time then it's OPERATOR OVERLOADING" than it is to start with the terms POLYMORPHISM and OPERATOR OVERLOADING and try to learn what they mean and what they are good for.
I think the problem is more along the lines of thinking that OOP means one specific subset of a long list of features. I agree that it doesn't matter much what the feature is called in any given implementation. PG has published such a list by Jonathan Rees here: http://paulgraham.com/reesoo.html
For example, it's much easier to go from a concept like "I can use the SAME NAME for DIFFERENT FUNCTIONS in the SAME PROGRAM, and there are various ways to map useful semantics onto the resulting code" to "If I resolve the ambiguity at run-time then it's POLYMORPHISM and if I do it at compile time then it's OPERATOR OVERLOADING" than it is to start with the terms POLYMORPHISM and OPERATOR OVERLOADING and try to learn what they mean and what they are good for.