On traits, I have seen that lots of people have lots of verbiage about it, but I've skipped that because my provisional opinion at Re: Re: very simple per-object mixins about mixins is also my provisional opinion on traits. They are a bad idea unless they are done a lot, with a relatively few examples being done. Then they become good.

On the version of can that you provided, I assume that you had a typo, you wanted the return to be return sub { $self->$method(@_) }; In which case your solution becomes the same as the one that simonm came up with at Re: Re: Re: Re: Re: Re: Re: Why breaking can() is acceptable, and my reply at Re: Re: Re: Re: Re: Re: Re: Re: Why breaking can() is acceptable. My point that I'd expect people to come up with this answer and not noticed its issues has been strengthened by the fact that that has now happened twice in a row.

If you want to take Class::FlyweightWrapper to the next level, be my guest. I'm not particularly interested in it because I'm not using it. It wasn't hard to implement the first time, and the fact that I'm not using it means that I don't have any intuition on where people will have issues with it.

On the other 2 implementations. While neither is aimed for widespread use, both are functional enough to be used in a local project. I wouldn't be surprised if a lot of real production code that uses AUTOLOAD is at a similar level, excepting the fact that real code has become longer because people have kept on adding stuff to it.

About diversity, that is a good thing about Perlmonks. You're right about the likely outcome, but hopefully this thread gives you some perspective about why at least some people won't pay as much attention as you would like to your insisting.