Return structure on JS Module Pattern

Building a best practices for a manual on Module Patterns (for an internal's firm course) We come to the needs of easy discussion on the public contract and the persistence of each object. So the team is divided between two structures:

CLASSIC:

// Namespace for the library
var myFunPattern1 = {};

// Library definition
myFunPattern1 = (function () {

    // Private variables / properties
    var myPrivateVar = "anyValue"

    // Private methods
        function anyPrivateMethod(parameter) {
            ...
            return "whatever";
         }

    // Public API
    return {
        anyPublicMethod: function (parameter) {
            ...
            return "whatever";
         }
    };
})();

THE OTHER:

// Namespace for the library
var myFunPattern2 = {};

// Library definition
myFunPattern2 = (function () {

     // Public API
     return {
        anyPublicMethod: internalNameForPublicMethod
    };

    // Private variables / properties
    var myPrivateVar = "anyValue"

    // Public methods
        function internalNameForPublicMethod(parameter) {
            ...
            return "whatever";
        }

    // Private methods
        function anyPrivateMethod(parameter) {
            ...
            return "whatever";
         }

})();

we see the first of more "code elegant" while the second enables faster development and clear conversation between teams (once the return is defined with the documentation for parameters and so on, each developer can start working on the rest of the code

also, changes on the functionality (i.e A/B testing on function performance), on first mode need to be changed the function, on second, only the internal reference. Even, that may could be done dynamically ...

some of us think the second may raise some inconsistencies and force dependencies (public functions being declared first, or invoque before declaration), others we think we are safe ...

any other consideration??