That sounds like it's only an implementation difference.

You could compile Objective C with a profiling or global analysing compiler that compiles method calls to different things depending on the class of the object if you wanted to, and you could compile Java with an approach that compiles to the same thing regardless of the object's class if you wanted do.

But message passing is always described as a programming model, not an invisible implementation detail.

The difference in the programming model is that in a message passing language you can define logic around the handling of the message. Usually that logic is nothing more than passing to a method, but in some cases you may want to have other behaviour which you can write code to define. The other behaviour is what is absent from languages where methods are implemented as a jump as described by the parent.

The difference described in the post one level up is basically the difference between C++ virtual and non-virtual methods. It is not an invisible thing. Virtual methods behave differently than non-virtual ones.

No, it's a bit more general than that. It's the difference befween C++ virtual methods, pointers to which are stored in an array and always called by array index, and Python methods which are stored in a dictionary and called by name. In fact you can say that Python (unlike C++ or Java) implements message-passing semantics or is at least equivalent -- since in order to invoke a method, a caller's implementation needs know nothing about the method or its class except the method name, arguments, and a rederence to the target object.

Also implicit in message passing is a form of structural typing; objects that understand the same set of messages (called a protocol in Smalltalk-speak) are type-equivalent. A client class may delegate to any object that understands the messages the client sends to its delegate. One of the advantages this brings is all the crazy things you can do with #become: in Smalltalk. A perfectly valid way of responding to a message you haven't implemented is to construct an instance of a class that has an implementation for that message, and then become: that instance, swapping all references to yourself in system memory with a reference to the instance you created before passing the message onto the instance (your new self). There's no way to implement general #become: in C++ or Java because there's no guarantee the result will be sound type-wise.

The changes are subtle but they open up a world of dynamism that Java programmers don't have access to. Which is fine for Java programmers, who decided they don't want that kind of dynamism anyway, but there are programmers who work better shaping a live system rather than declaring type ontologies in advance. And Smalltalk is designed to work well with such programmers.

But that's what I mean - you could implement non-virtual methods using the same technique as virtual methods, if you wanted to. And using static analysis or profiling you could implement virtual methods as non-virtual methods.

Are you telling me that if I turn on a compiler optimisation my message passing program suddenly becomes a method call system?

So the difference cannot be what it compiles to.

You can not turn your virtual methods into non-virtual ones without affecting what your user-level program does. You decide whether you use virtual methods or not in your C++ program, not the compiler. They affect what your program does not simply how it does it.