I deliberately tried to steer away from any particular programming language, but if you received the expression that I'm talking about those three, my apologies.

Well, it just seemed to me (and I may have read in between the lines too heavily and I apologize in advance if that is so), that much of what you were talking about were problems with particular OO implementations and the more idiomatic usage of said OO implementations. For instance, in CLOS programming it is not uncommon to have many plain vanilla functions (and macros) along with the classes and generic functions. The same can be said of much Javascript and C++ programming as well. It is only languages like Java which do not allow vanilla functions/subroutines to exist that the "pure OO" approach tends to win out (mostly because there is no other choice).

The point was not to compare programming languages, but to explain why the means of abstraction and combination in pure object-oriented thinking do not appeal to me in general.

Well, I think it is very hard to discuss abstract OO thought without at some point coming back down to the language level. Every OO system has it's own set of rules and therefore has its own set of limitations, and some systems contradict or are in direct conflict with one another. A "pure OO" system which is not tied to any language would need to be defined before it can be discussed. As for discussing the merits of the parts of OO like abstraction, polymorphism, encapsulation, modularization, etc etc etc, that discussion too will eventually need to come back down to a particular implementation for all the same reasons.

My point is basically that there is not such things as "pure object oriented thinking" which is 100% language agnostic.

My "functions are modules" argument doesn't mean first class functions or doesn't even presuppose functional programming.

I am a little confused by what you mean when you say "functions as modules", this makes me think of the Standard ML module system and functors in particular. A function being a function which takes a module as an argument and returns a new module. Is this what you are refering too? If not then I am totally confused by your use of the word "module". Please expand.

If I am worried about pervasive OO thinking in Perl 6, it's because frequently I don't want to think in terms of objects.

This is exactly my point, you wont have to think it objects if you dont want too. This is a stated design goal of Perl 6.

The concept of roles resembles Objective-C protocols, though with being able to define not only which functions the implementing class needs to provide but also some common functions that all classes implementing the role "inherit".

No, that is totally wrong actually. Obj-C protocols are pretty much the same as Java interfaces, and therefore are about as use{ful,less}. Roles (optionally) provide an implementation as well as just abstract interfaces. This makes them more akin to mix-ins or multiple inheritance. However, unlike mixins or MI, roles are actually composed into the class (in perl we do this with symbol table operations to copy from the role package into the class the role is being composed into) which means there is no inheritance relationship between the role and the class. There is also a strict set of rules by which roles are composed into classes, which makes for highly predictable behavior, whereas MI and mixins are much more difficult to predict behavior-wise.

However, this would again be a much more useful technique to think about if there was no mandatory link to objects and classes!

Well actually, they don't have to be linked to objects and classes at all. Roles are very similar the OCaml/SML module systems in that they can be used to compose a non-OO module just as easily as they can be used to compose classes. In fact, I have one specific usage of roles which uses pure roles as "function groups" which can be composed together (following the rules of role compositition) and are then used as "function groups" and never actually composed into classes/objects.

I'll install Moose::Role some rainy day, I promise.

You won't like it because it comes with the entire Moose object system. And that is deep down OO to the core, complete with metaclasses and all that fun OO-over-abstraction you seem to really dislike. In fact it is a meta-circular object system so it is actually OO that is implemented in OO. Which I am sure just makes you cringe :)

So, in conclusion, I think you have many good points, but your anti-OO stance seems to me to be somewhat reactionary to the pro-OO zealots. All good programmers know that silver bullets don't exist and in the end you just need good tools to get the job done. Those tools may be OO-based, they may be full of FP madness, or they may be a crusty CPAN module from the mid-90s like FindBin that sucks horribly but (for the most part) works when you need it to so you just use it and move on with your life. The moment you exclude any of those tools on some philisophical, moral or religious basis, you are really just adding more work for yourself.