If Class::Std or "some of the others" interfere with some other tool, why do you blame Class::Std and some of the others, and not the other tool?

Have you looked at how Class::Std is implemented? It's pretty crazy. It includes some "worst practices" too, like use of the UNIVERSAL:: namespace.

"inside-out objects" as a name doesn't suggest anything about being standard

The name is Class::Std, i.e. "Class Standard."

we'd still be using the indirect object notation, because that's how we used to teach programmers in the literature. Views change over time, and documentation isn't static.

If Class::Std ever became a very common way to do things, to the point where the Perl man pages used it in their OO examples, I would drop this objection. I think the difference between Class::Std and normal OO perl is a lot bigger than these other examples you gave though.

we'd still be using the indirect object notation, because that's how we used to teach programmers in the literature. Views change over time, and documentation isn't static.

You're misunderstanding me. What I'm saying is that any attempt to enforce encapsulation is ultimately futile when the other person has the source and can simply change your code to expose things that they want. I will grant that it's much harder to do than it is with simple hash-based objects though.

UPDATE: Class::Std does not actually put things in UNIVERSAL::. This technique is suggested in the inside-out objects section of the PBP book, but not used in Class::Std.

What I'm saying is that any attempt to enforce encapsulation is ultimately futile when the other person has the source and can simply change your code to expose things that they want.

You are completely missing the point of inside-out objects. The point of inside-out object isn't to prevent accessing data. The point of inside-out objects is on the one hand to prevent accidental access of data (collisions), and on the other hand to give you compile time errors when making typos in the attribute names.

Inside-out objects is to OO programming what 'use strict', lexical variables, and name-spaces are to non-OO Perl programming. None of it prevents anyone from getting to anything one wants - but that doesn't mean 'use strict', lexical variables and name-spaces aren't very good ideas.

"inside-out objects" as a name doesn't suggest anything about being standard

The name is Class::Std, i.e. "Class Standard.

Let me recall what you wrote:

And finally, I don't use them because, despite the name, they are the exact opposite of standard.

That's plural. The thread is named Seeking inside-out object implementations. If your objection is about the name of a single module, then the use of plural is misleading. It would also mean that that objection doesn't hold for different implementations of inside-out objects.

Unless you want to claim that the name of inside-out objects is "Class::Std". In which case you are utterly wrong. "Class::Std" is a way of implementing inside-out objects, not 'the way'. Dismissing inside-out objects based on a single module is like dismissing databases because you don't like MySQL, or dismissing cars because you don't like Fords.

When putting a smiley right before a closing parenthesis, do you:

Use two parentheses: (Like this: :) )
Use one parenthesis: (Like this: :)
Reverse direction of the smiley: (Like this: (: )
Use angle/square brackets instead of parentheses
Use C-style commenting to set the smiley off from the closing parenthesis
Make the smiley a dunce: (:>
I disapprove of emoticons
Other