So my first concern with this approach is that you are overriding the accessors and returning a value that is in conflict with the type declared in the attribute. This is just bound to confuse someone at some point.

My second concern is that you are blocking access to the underlying NetAddr::IP objects via the normal and expected accessor methods. This means that if someone wants/needs to get at the NetAddr::IP objects they must use raw HASH access. Essentially your code is forcing someone to do something they very much should not do.

I suggest you follow ikegami suggestion in Re^6: Why does changing a Moose attributes' properties remove the around modifier and use the 'handles' option to get the addr return value but still keep access to the underlying NetAddr::IP object if you ever need it.

Actually, why not just add a 'decoerce' or 'deflate' or something to the accessor, a coderef that gets run against a value as the value is being returned? It'd allow a (deflate => sub { $_->clone }) to be applied to a DateTime accessor, for example, to make sure a end user doesn't ->add() to your internal value, etc, while not being spooky action at a distance; it's just another attribute of the accessor that can be changed or ignored or overridden by inheriting classes.

This might make a good MooseX:: module, I suggest giving it a try (though I think 'deflate' is better then 'decoerce'). It is the policy of the Moose core to not add any feature that has not been successfully implemented and tested as a MooseX:: module, this helps us to avoid running into back-compat issues.