If everyone had your attitude, then I wouldn't have seen a point in having the discussion either. The issue is that there are people who think that any module which decides that can() shall not be supported is broken. Since you apparently agree with me that breaking can() is OK, we would have had little to discuss.

As for the solution that you provided, it tries to do a good job, but still has several subtle issues with it. First of all, and glaringly, your $AUTOLOAD always includes the package name and so will fail to do any kind of inheritance. That can (and should) be readily fixed. Secondly your AUTOLOAD fails (uninformatively) if you accidentally call an unimplemented function procedurally in any class that inherits from it. Thirdly if you appear partway up the class hierarchy in a multiple inheritance scheme, you will implicitly prune the class hierarchy for AUTOLOADed stuff to that hierarchy, contrary to what you claim about it being a working way for using AUTOLOAD with multiple inheritance. That is a common AUTOLOAD problem, your can matches what your AUTOLOAD does. (And it is a common multiple inheritance problem, people tend to think about the cases where they are at the bottom or top of the hierarchy, and don't think through being in the middle of the inheritance tree.) And finally it is worth noting that anyone who tries to do what I suggested with a UNIVERSAL::AUTOLOAD to allow can() and AUTOLOAD to play together will find that things implemented with their AUTOLOAD override yours. (Ironically this is probably a good thing.)