It's even better than IPv4 with NAT since it will actually rotate in new random IP addresses every so often (every hour or so). That means that your source IP will change over time which makes tracking harder.
Let's pretend I'm stupid (which should be easy for you since you either seem to be convinced I'm intellectually inferior to you, or you are just being a condescending arse) and explain to me what part of method dispatch is done statically (in a "non-message-passing system" vs. dynamically in a "message-passing system").
Since you are arguing that these methods are so fundamentally different, I would expect to be able to see functionality in the latter that just can't be achieved in the former.
I argue that, once you strip out the terminology and look at what these systems actually do, there is not real difference.
Of course, in highly dynamic systems you need to recompile method calls on the fly, but that is true for languages like Java as well, which also needs to do this.
Finally, CLOS has the most flexible method calling in existence. You can write your own methods that chooses the appropriate method to call (look up define-method-combination for the gritty details). Amazingly enough, it still manages to compile the method invocations into direct calls.
That said, the actual underlying implementation of the compiler is completely irrelevant in this case. The actual provided functionality available to the programmer, is. And from the point of view of the programmer, the difference between message passing and nay other calling style is minimal, at best.
The actual dynamic behaviour that you talk about has nothing to do with the object orientation at all. The "invokeMethod" that you talk of is simply the FUNCALL or APPLY functions that simply calls a function.
At the end of the day, regardless of how you choose to think about object orientation conceptually, all that really happens is that some code is called based on some property of the arguments that you pass in. The most common form is simply the choice of implementation based on the runtime datatype of the first argument.
Here's the important point: If I were to give the following statement: "Java uses message passing", it's actually very hard to contradict that. Every single feature and behaviour of message passing systems you mentioned above with the exception of having a fallback implementation can be replicated in Java with just a bit of reflection. If the designers of Java had really wanted (and IMHO, they should have) they could have added the necessary extra syntactic sugar to achieve that.
Whether or not an "actual" message object is constructed that is passed as an argument to a dispatcher, or if the compiler creates a vtable is really an implementation detail and as a programmer you very rarely, if ever, see the difference. You seem to have confused the difference between static and dynamic languages with that of object orientation style.
If you still feel the desire to reply, then I really would like to know how you categorise generic functions (in particular, the CLOS kind) in terms of message passing vs. something else.
Having the actual method implementation tied to a class (as is the case in most languages, including Java and C++) is again an implementation detail, albeit one that can limit the flexibility available to the programmer.
Extrapolating this further brings us to generic functions which are just plain functions which is a dispatcher to multiple implementations. I'm sure one can argue for hours whether or not that is message passing or not.