This is written to be an object method but it effects the object's package namespace not the object.

Um, that statement leaves me unsure what code you were reading when you wrote that. :) What I wrote is closest to being a class method; it certainly isn't an object method. But the similarity it has to being any kind of method at all is only in that it follows the convention set forth in Perl 5 as to how 'use' works. It also doesn't "affect the object's package namespace" (there are no objects involved, so s/object's package namespace/package/); it impacts the namespace of the other package(s) that use this module.

If there is already a My::Config­::import function, it would be better to change the lexicals to package variables inside My::Config.

Huh? There was not already an My::Config::import(). There wasn't even a My::Config, there was just a file with no package declaration and an our %prod declaration.

This is code that should not be applied to mature code since the My::Config module needs be invaded and all the client code needs to be altered to use it.

If there had already been a My::Config::import(), then the interface would be exactly the same and no "client" code would need to be altered. Code that uses the theorized My::Config should not care at all how the hash you ask to be exported is implemented internally.

If writing new code, such misuse of lexicals is perverse. ... That is the thing I like about it. Ahh.

Well, that is a clear statement of opinion. But I wish I could understand the reasoning behind that opinion. (: