Surely changing inheritence on the fly is against the idea of the OO patterns in the first place? If you need to change what output you provide by dynamically changing inheritence then I don't see how you can say this alternate technique is OO based. I would be interested in seeing arguments to say that it is.

I have my own arguments against this:

By changing the inheritence dynamically (assuming, of course, that it were possible in any language) you are replicating the same process as interfaces (well sort of). So why muck with the chain (which can have interesting side effects) when the principle of the strategy pattern is to load objects capable of completing the responsibilities of the task via the interface required. The contract is between the calling code and the interface and you assume that it will do what you want. By working on the problem via changing inheritence you are circumnavigating that contract. Ok if you are a sole programmer. Not ok if you are working in a team (or across companies). Its certainly frought with problems.

If this were available I think I would be pretty safe in saying that I would never make use of it.

If you need to change what output you provide by dynamically changing inheritence then I don't see how you can say this alternate technique is OO based.

I'm not into making rigorous definitions of OO, nor am I arguing that this technique is or isn't OO in any kind of purist sense. But considering that it is all about inheritance of methods, I don't know what other drawer to file it under. Remember that Perl's OO is not (much) like any other language's OO. One of the ways in which it's different comes from the highly dynamic nature of the language itself. And this technique is merely an example of that.

If this were available I think I would be pretty safe in saying that I would never make use of it.

It is available. And no, I don't actually expect anyone to make use of it. :-)