But what if the the classes are intentionally written and maintained with this in mind? Users don't even need to peek inside when the action is supported through methods. Maintaining sibling subclasses that rely on the same parent doesn't seem abusive or even unusual.

An example of my own use is dealing with user instances. Prior to validation, users interact with the system via an instance of the anon_user class. Should they log in, their instance is elevated into one of the user classes (depending on their status). The effects of some methods will change, and additional data might get grafted on. But I also want all the information I've already collected when I go to create their validated user object, and lo, there it is behind the anon_user veil, ready and waiting. Sometimes they go through a cascade of changes in user-type. What would be the object-appropriate way for me to go from one state to the next in such a situation?

I can agree with you that it doesn't make sense to grab a random data structure ("how it's implemented") and start abusing it. The author should have the freedom to make any changes they want under the hood. But when you are the author, such preservation and re-use of data structures seems prudent if applicable.

Have the user object contain an authorization object. Then, when the userobj wants to know if it's allowed to do certain things, it asks the authobj. The authobj replies with a boolean yes-or-no.

The reblessing you want to do is really changing the authobj. So, just change the authobj! There's no need to get all fancy. In fact, a good rule of thumb is "If I have to ask if something is possible on Perlmonks, I probably should rethink my design." About 90% of the time I ask a question, my design changes. This is a good thing.

---

My criteria for good software:

1. Does it work?
2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?

But what if the the classes are intentionally written and maintained with this in mind?

Then I'd ask why you wrote this code as OO, since you aren't getting a major benefit of OO: abstraction.

There are many common approaches for doing the kind of thing you describe that don't require breaking encapsulation. They're so common that they have design pattern names, like "decorator" (wrap one object with another), or "strategy" (delegate the handling of certain methods to different objects determined at runtime). You could also just use the original object's public API to get the data to populate the new objects (a "factory" pattern).