Not copying the parameter hash seems to leave the state of our new object open to the whims of another reference. Our capsule is dissolved before it is created.

I did mention that it wasn't necessarily best practice. I'd only recommend this if (a) efficiency was a primary concern and (b) I control the source of the hashref. Outside a custom hand-rolled class, it's really not a great idea.

I would appreciate your solution for HOHObjects or your other thoughts on this aspect of the matter.

I think it depends on the usage you intend. With traditional hash-based objects, people get their "strictness" with accessors. That approach still works with an HOH-inside-out object. It preserves the other benefit of inside-out objects -- subclassing anything. Another approach is the one that I'm experimenting with with Object::LocalVars, using a wrapper around methods to alias variables in file-scope to the right object-specific data. With that approach, I can implement with any underlying data structure. (Note, I'm not saying that anyone should do this -- merely that TIMTOWDI is still operative.)

Class::Std's prime purpose is to constrain clients to the interface. That makes me wonder for what purpose you would use something other than a scalar as an object here

Well, with all due respect to TheDamian, Class::Std is just one particular implementation of the inside-out paradigm. It has embodies design choices that make it better for some applications than others. From what I can tell, it's designed to facilitating creating large, complex, internally-consistent, extensible class hierarchies. That means it does other things less well.

As an example of why one might use something other than a scalar, the classic example is when you want to subclass a module that someone else wrote on CPAN. You want to add functionality and additional state, but you don't want to tightly couple your subclass to the parent class's implementation. (What if it changes? What if they add keys that collide with yours?) With the inside-out approach, it doesn't matter -- you construct the parent object, rebless it to your class, and then initialize your own state. It's completely orthogonal to the parent implementation.

Another example would be when you want the object to be used like some other type of data than just an object. For example, you want a filehandle that you can print to, but that you can call methods and also save state. With traditional objects, if you want state, you can't use a blessed globref as the object. You can tie a class to a filehandle, of course, but then you have all the tie overhead. Instead, with an inside-out object, you bless the filehandle reference as the object, and store the state externally just like for any other inside-out object. Again, state is orthogonal to the type of blessed object.