Thanks for the feedback. Perhaps Module::Stub is a better name. I also like your idea for using importer semantics instead of calling stub.

I was aware of Test::MockObject, but not MockModule. However, these are tools for writing tests; I intend Module::Stub to be more general purpose, and useable in production code.

Also I would be sure the stub module is properly added to the %INC hash, otherwise require and use will try to load the real module. (you may have already done this, but you didn't post code, so I don't know).

This depends on the circumstances. I am intending to stub when the module is not installed on the target system, so the 'real' module won't be there anyway. But a lot depends on how Module::Stub is going to be used.

Regarding the status of the module, I have not written any code yet, just the POD sections I posted in the root node. I do feel that there is sufficient interest here, and I will spend time on it and release the module. I will address the API issues of subclassing or plugins as I develop it. I also agree with your last sentence and revdiablo's comment - I want this module to be accessible to a large audience, which does not have a grasp of Perl's arcane features, such as symbol tables, coderefs in @INC, the %INC hash, etc.