I'm going to agree with dragonchild, if you are going to do AUTOLOAD stuff then you should implement a version of can for your class. This is basic interface polymorphism (another of chromatic's pet peeves), you should be able to expect that inherited methods called on your object behave in a resonably obvious/intuative way or have a very good reason not too. Sometimes, this means not relying on the default implementation (UNIVERSAL::can) and instead write a custom implementation.

Part of the idea of using AUTOLOAD is to hide the implemenation (methods not being implemented) from the user of your class. If in doing so you break can (an expected inherited method of the UNIVERSAL base class) then you are breaking the object, and your code is incomplete.

I would even go so far to argue that if you cannot write a version of can that functions as a transparent replacement, you should re-think your use of AUTOLOAD in the first place.

I see no reason why it should be left broken or that you would need to make method stubs. It should work as expected, nothing more, nothing less.