Problem with a table of functions defined within a table definition

[Jake-NotTheMuss]

Issue

There seems to be a decompiler bug that I noticed in the file lua.Lobby.Common.LobbyCore. In this file, a table is defined like the following:

Lobby = {
    ProcessTree = nil,
    Navigation = {},
    Core = {},
    HANDLER_TYPE_FWD = 1,
    HANDLER_TYPE_BACK = 2,
    Core = function ( fromTarget, toTarget, handlerType, handler )
        if Lobby.Navigation[fromTarget.name] == nil then
            Lobby.Navigation[fromTarget.name] = {}
        end
        if Lobby.Navigation[fromTarget.name][handlerType] == nil then
            Lobby.Navigation[fromTarget.name][handlerType] = {}
        end
        Lobby.Navigation[fromTarget.name][handlerType][toTarget.name] = handler
    end,
    Core = function ( fromTarget, toTarget, handler )
        local handlerType = Lobby.HANDLER_TYPE_FWD
        if Lobby.Navigation[fromTarget.name] ~= nil and Lobby.Navigation[fromTarget.name][handlerType] ~= nil and Lobby.Navigation[fromTarget.name][handlerType][toTarget.name] ~= nil then
            error( "LobbyVM: A forward handler already exists from '" .. fromTarget.name .. " to " .. toTarget.name )
        end
        Lobby.Core.AddHandler( fromTarget, toTarget, handlerType, handler )
    end,

In this file, 6 functions are defined within the Lobby.Core table:

Lobby.Core.AddHandler = function(fromTarget, toTarget, handlerType, handler)
Lobby.Core.AddProcessForward = function(fromTarget, toTarget, handler)
Lobby.Core.AddProcessBack = function(fromTarget, toTarget, handler)
Lobby.Core.GetForwardProcessFunc = function(fromTarget, toTarget)
Lobby.Core.GetBackProcessFunc = function(fromTarget)
Lobby.Core.GetMainModeStr = function(mainMode)

In the decompilation, however, these functions are simply named "Core", overwriting the Core previously defined. Each function is simply defined in the form Core = function() ....

I also have a question about something within this same file that I can't find any answers to online.

Question

In the function Lobby.Core.GetBackProcessFunc(), there is a call to pairs():

if backNavTable ~= nil then
    local f5_local0, f5_local1, f5_local2 = pairs( backNavTable )
    local backMenuName, handler = f5_local0( f5_local1, f5_local2 )
    if backMenuName ~= nil then
        f5_local2 = backMenuName
        return LobbyData:UITargetFromName( backMenuName ), handler
    end
end

This snippet is taken from a decompilation of the beta version of the script. I am using the beta version to highlight the fact that certain variables do not have names and are therefore decompiler-generated. The current version of the same script decompiles the same way, resulting in an identical result, only without any variable names.

What I'm trying to figure out is what this function should look like in source. Since the 3 variables assigned after calling pairs() do not have names, in the source, the call to pairs() was not assigned immediately. It was part of a more complex expression, than assigned to the variables backMenuName and handler.

Having an extra parenthesis after the pairs() call would then call the 1st return value of pairs(), like the following:

local backMenuName, handler = pairs(backNavTable)()

But what I am confused about is how the 2nd and 3rd return value of pairs() were used as arguments to the second call. Could you enlighten me on this problem?

UPDATE 7/25/22: It seems this is caused by a for loop which returns or breaks unconditionally. I don't know if it's the compiler optimizing away the loop, or if its the decompiler not recognizing it as a loop. In any case, the source would probably looked like the following:

for backMenuName, handler in pairs(backNavTable) do
    return LobbyData:UITargetFromName(backMenuName), handler
end