What's your point? In CL it is trivial to determine both at compile and at runtime the package of all symbols involved. Same for generic methods, you can query the runtime which methods it is going to use for some concrete combination of parameters. Much easier than to determine how which overload of a C++ operator does the compiler/linker deem to fit in given context.

My point is that this:

> Most implementations of Common Lisp prevent shadowing builtin symbols.

is irrelevant. It's actually irrelevant for two reasons. First, the example under discussion was SQUARE which is not a CL builtin, and second, even if it was, you could just do this:

Just make your own package and do:

(in-package :my-package)

(defmethod square ((n number)) (* n n))

Now you can extend SQUARE to work on things other than numbers. Or, to pick a more realistic example:

(defmethod sqrt ((n number)) (cl:sqrt n))

Oh that's the misunderstanding, I was talking about overloading of the '*' operator and the consequent confusion, not overloading of 'square'.

* is not an operator in Lisp. It's a function. Lisp doesn't have operators.

To be more precise, cl:* is a function. But you can make a symbol named "*" in another package and define it however you like.