That’s what it seems like, but it’s clearly… why do I even go on the internet lol.
Anyways, there’s no reason for multimethods to be part of single dispatch syntax, and Bjarne thinks the Julia way of doing it is the right way to express it as of 2019:
Unified function call: The notational distinction between x.f(y) and f(x,y) comes from the flawed OO notion that there always is a single most important object for an operation. I made a mistake adopting that. It was a shallow understanding at the time (but extremely fashionable). Even then, I pointed to sqrt(2) and x+y as examples of problems caused by that view. With generic programming, the x.f(y) vs. f(x,y) distinction becomes a library design and usage issue (an inflexibility). With concepts, such problems get formalized. Again, the issues and solutions go back decades. Allowing virtual arguments for f(x,y,z) gives us multimethods.
So the updated version from the mouth of the author to that paper is, the OOP syntax was a bad idea and it should all be about multimethod semantics on f(x,y,z). So (a) multimethods are not OOP and (b) OOP syntax is not necessary or sensical to use with multimethods.