The more, the merrier. Personally, I like the minionize($hashref) option better, mostly because it avoids creating two packages for every class I want.

The implementation of the methods passed as anonymous subroutines in the %Class hash seems a bit difficult to read though. Still, this could probably be avoided:

use Minions ();

my %Method;    # maybe this hash could be already imported into
               # the namespace with a param passed to Minions
my %Class = (
    name => 'Counter',
    interface => [qw( next )],
    implementation => {
        methods => {
            next => $Method{'next'},
        },
        has  => {
            count => { default => 0 },
        },
    },
);

$Method{'next'} = sub {
    my ($self) = @_;    # maybe this could be avoided with some sugar
    $self->{-count}++;
};

Minions->minionize(\%Class);
[download]

If there would be some more sugar to facilitate writing the package this way, I would like it even more. Is the line interface => [qw( next )], needed? Maybe it could be replaced with public_methods => {...} section within implementation, and all the methods added there would automagically land in interface => []?

The documentation says nothing (or I did not read it carefully enough to find it) about how Minions behaves when stuff goes wrong. On the other hand, the fact that you provide code examples wrapped in simple tests, is wonderful. More examples should be written this way.

Looking forward to future updates. Best luck with your distribution.