Side note: just because you can't see where it's coming from isn't always a bad thing. It makes it easier to adjust the behaviour.

Option 1: Say you have a MyModule with timestamp in it. Now a new corporate standard says all company-owned modules should be in the Example namespace. All you need to do is change the modules themselves (including moving them to the Example subdirectory) and the "use" statements. The rest of the code will work as-is. (This is also a reason to use __PACKAGE__ when referring to one's own package rather than hardcoding the name again and again - the other reason is to aid in cut&paste from module to module.)

Option 2: Say you're using CPANModule's timestamp. And you find a bug. So you go write MyCPANModule, reimplementing a timestamp that works, and all you need to do is change the use statement. You don't need to go changing all the code.

Option 3: Say you're using CPANModule's foo function. Which calls CPANModule2's timestamp - which is broken or just not working quite the way you want it to. If CPANModule is calling "timestamp" rather than "CPANModule2::timestamp", then you can just "use CPANModule" and then play with the symbol table and "import" your own timestamp function into CPANModule's namespace with whatever modifications you want, which will overwrite the import from CPANModule2 since the import from CPANModule2 will happen during compilation and yours will happen during runtime. (Technically, it could be during compilation as well, but after the compilation of CPANModule and thus also after compilation of CPANModule2.)

Part of the idea of not naming your namespaces is to allow perl to actually Do What You Mean. Even if it's not your code ;-)