Over the years I have found that I have rarely, if not never, had occasion call $obj->new() if for no other reason than the desired result is usually ambiguous. Granted for many years I put in the usual code under discussion because I thought it might be handy to get the class name from an object.

Today, I almost always put in code such as this: croak 'Must be called as a class method' if $ref($class)' I also often use something like this in methods: croak 'Must be called as an instance' unless ref($self) (And I generally put in param count and validation checks that croak.) In my experience this saves a lot of time tracking down bad code, especially in a multi-team environment.

What annoyed me was that I could not use that code in Moo's BUILDARGS due to the code being generated in the constructor. In fact, the only way to accomplish that was to use before new, which has been pointed out by many is not a good practice. In this particular case, I don't think it has much of a downside, but I do think Moo (and by extension Moose) should allow for generating a constructor that takes that into account.

The goal is not OO purity, but rather, easy to understand code that someone can grasp a year from now. On a side note, I have long maintained that one cannot fully appreciate just what Moo is doing without a good understanding of classic OO Perl. I can readily see what you mean when you say Moose is anti-modular. I would be more inclined to say that there are those who have taken modularity to an extreme with it and have lost sight of a project's architecture in the process.

By the way, I have avoided Moose for a long time because of the size and performance issues that we all know so well. However, I am favorably impressed by Moo on both counts. It provides the basic functionality that one wants from Moose, and has surprisingly acceptable performance. The parts of Moose that Moo is missing actually seems like a Good Thing(tm) to me as it tends to prevent one from getting carried away with unneeded complexity.