Thanks for adding it. I think as you get into defaults, lazy defaults, BUILD/DEMOLISH and roles, you'll start seeing clearer similarities and differences.

I'm bummed you didn't also show Class::Tiny. It's similar to Object::Tiny, but you get RW accessors, lazy attribute defaults and a BUILD/DEMOLISH system like you get in Moo(se).

I mentioned in passing in my post on the topic that 'Pumpkin v20' is a bad idea if the regular annual releases continue to be v22, v24, etc. We don't want annual, generally backwards-compatible releases to be bumping major versions like that or when we do make a major change, there's no way to tell "minor" major versions from "major" major versions. Thus, if this change is made, I favor "Pumpkin Perl 1, version 20" so there is room for a "Pumpkin Perl 2" later. There are other version solutions that accomplish similar things, but mostly, I want to convince people that the idea of just using the annual release version as the major version is not a very good idea.

I think you're absolutely right that if you don't ever use old Perls, then it's not a big deal any more. As much as I might wish it, though, that's not everyone. Many people writing for CPAN like to support older Perls too, and I see lots of people get tripped up with v1.2.3 style version numbers. Just today on #toolchain on IRC there was a question about why 0.4.2 compares as less than 0.4. Those kinds of questions are *still* coming up 12 *years* after v-strings were introduced in Perl v5.6, so something about it still just doesn't compute for many people, even after v-strings were improved in v5.8.1 and after version objects were added in v5.10. Will 'package NAME VERSION' syntax in v5.12 finally make the difference? I hope so, but I'm not holding my breath.