For me, OO means stateful objects communicating by message passing, and same as asdasf, I consider it a way to structure imperative code. I don't consider this a perversion - it goes back to Kay.
Your definition is of course an equally valid one that might be more appropriate in certain contexts - it just doesn't fit my mental model of computation equally well.
I've developed the opinion, based in large oart on Kay's thinking, that the biggest wins of OO are better represented as a form of protocol design. The point of impedance comes in when you discover that not all protocols map cleanly to OO systems - some are synchronous and others asynchronous, some require more polymorphism than others, etc. Async message passing happens to be one of the more flexible mechanisms for protocol design, but it's only been relatively recently that industry languages have been considering it more carefully, and then it's framed as "concurrency" and not a general architectural consideration.
Likewise I see FP as a reactionary mechanism to write fewer and simpler protocols, because when the data is immutable the problem can usually be greatly simplified.
Your definition is of course an equally valid one that might be more appropriate in certain contexts - it just doesn't fit my mental model of computation equally well.