This module attempts to straddle the line between strong encapsulation and DWIM. Its major features appear to be integrated trace logging and dynamic definition of attributes.
Unfortunately, it demonstrates a poor understanding of the nature and limitations of the inside-out object technique -- it's more akin to Conway's original "flyweight" pattern than a true inside-out object. Some observations:
* it stringifies the object for accessing the underlying lexical storage, which will break for objects that overload stringification; (refaddr should be used instead)
* lexical storage is a single hash in the base class namespace instead of using lexical storage in the derived classes; thus all attributes have method overhead for access and even private attributes are declared and accessed through methods
* as a result of the above, there are no compile-time checks for typos in the names of attributes, which is one of the frequently cited reasons for using the inside-out style
* worse, because attribute declaration is done via AUTOLOAD, attribute typos won't even be caught at run-time, but instead completely new, misspelled attributes will spring into existence
* hashification returns a reference to the underlying data rather than a copy of the underlying data, thus providing an API for breaking the encapsulation provided by using the inside-out style in the first place
* not thread-safe (via CLONE method or other approaches) -- though the author notes it hasn't been tested for threads
* forces the use of a blessed scalar in new, preventing foreign inheritance, which is one of the other reasons frequently cited for using the inside-out style; doesn't use the scalar for anything useful to compensate for this loss (such as storing a globally unique ID that could be used instead of object memory address for thread-safety)
* not serialization compatible via any of the standard tools, like Storable; the only serialization provided is dumping via Data::Dumper and only to STDERR
In summary, while this module clearly works for the author, I strongly recommend that others avoid it until the author addresses many of the points above.
For inside-out objects, I recommend instead either Class::InsideOut (which I wrote) or Object::InsideOut. The first is simpler; the second more featureful.