Speaking of aesthetics, I find that example ambiguous. It's not obvious to me whether push is a method that just so happens to have the same name as the push keyword (the one which works on arrays) or whether it's an alternate way of writing that keyword. Is that a method which operates on a container (the array) or an object (not really a container)?

First, I'm not suggesting that the example makes perfect sense. I didn't chose it, I just matched it.

That said, I have absolutely no problem with an object, (regardless of the internal representation), (re)using a perl keyword for one of its methods, provided that the semantic of that method match those of the keyword. After all, isn't the separation of namespaces one of the primary benefits of OO?

In fact, given that keyword 'push' has been used for the semantics of (various) ADTs (stacks, FIFOs, LIFOs, etc.) in many languages that long pre-dated Perl; and is still the opcode mnemonic used for the equivalent hardware stack operation in (probably) every assembler and hardware manual for every processor going; I think it would be quite silly not to use that well understood term for objects that implement semantically equivalent operations.

In my mind, one of Perl's OO flaws is unnecessarily confusing containers and objects. An object may have containers, but should it be one?

I'm of almost the diametrically opposed position. I think that reusing the familiar and well understood semantics of containers for for classes that represent collections is both eminently sensible and infinitely preferable to everyone inventing their own disparate terms and semantics.

Other languages are perfectly happy to reuse container semantics for OO-classes. In the case of C++ its just a shame that it took the language standard so long to catch up with the rest of the world; with the knock on affect that they've had to invent verbose terms -- push_back, push_front, pop_back, pop_front etc. -- to avoid conflicts with previous 'unsanctioned' libraries.