Thanks @gengh for pointing me to the call being sent to the orchestrator.

In this case, the call to the renderer looks like

{
    "Z1K1": "Z7",
    "Z7K1": "Z16700",
    "Z16700K1": {
        "Z1K1": "Z16683",
        "Z16683K1": {
            "Z1K1": "Z7",
            "Z7K1": "Z16728",
            "Z16728K1": {
                "Z1K1": "Z7",
                "Z7K1": "Z803",
                "Z803K1": {
                    "Z1K1": "Z39",
                    "Z39K1": "Z16683K1"
                },
                "Z803K2": {
                    "Z1K1": "Z18",
                    "Z18K1": "Z17120K1"
                }
            },
            "Z16728K2": {
                "Z1K1": "Z7",
                "Z7K1": "Z803",
                "Z803K1": {
                    "Z1K1": "Z39",
                    "Z39K1": "Z16683K1"
                },
                "Z803K2": {
                    "Z1K1": "Z18",
                    "Z18K1": "Z17120K2"
                }
            }
        },
        "Z16683K2": {
            "Z1K1": "Z7",
            "Z7K1": "Z13539",
            "Z13539K1": {
                "Z1K1": "Z7",
                "Z7K1": "Z803",
                "Z803K1": {
                    "Z1K1": "Z39",
                    "Z39K1": "Z16683K2"
                },
                "Z803K2": {
                    "Z1K1": "Z18",
                    "Z18K1": "Z17120K1"
                }
            },
            "Z13539K2": {
                "Z1K1": "Z7",
                "Z7K1": "Z803",
                "Z803K1": {
                    "Z1K1": "Z39",
                    "Z39K1": "Z16683K2"
                },
                "Z803K2": {
                    "Z1K1": "Z18",
                    "Z18K1": "Z17120K2"
                }
            }
        }
    },
    "Z16700K2": "Z1002"
}

There are a few Z18/Argument references that point to keys which don't exist in the function call, e.g.:

"Z803K2": {
                   "Z1K1": "Z18",
                   "Z18K1": "Z17120K2"
               }

Z17120K2 comes from the enclosing function call and only makes sense in that context. Therefore, we (correctly) get a Z525/Invalid key error (thrown in function-orchestrator:src/Frame.js:EmptyFrame:retrieveArgument.

The "right way" to fix this would be to allow the orchestrator to return partial results: we could run the original function call up until we are able to resolve this reference to Z17120K2 and return it early. This will be a nightmare. Realistically, we might need to resort to some heuristics in the PHP layer. I'd be happy to discuss either solution further.

It seems to me that in this case (showing the implementation composition), the string renderer shouldn't even come into play, unless the values are complete (there are no argument references).
Should we stop such cases from collapsing into the string renderer component and just stop that function call from running altogether?

Alternatively: we might consider having parser/renderer functions operate over Z99s. Then the parser/renderer functions themselves can handle Z7, Z9, and/or Z18 literals however they want, since these "nonterminal" types will be represented faithfully inside the Z99.

In T368320#10015662, @gengh wrote:

It seems to me that in this case (showing the implementation composition), the string renderer shouldn't even come into play, unless the values are complete (there are no argument references).
Should we stop such cases from collapsing into the string renderer component and just stop that function call from running altogether?

Yep, this is also a possibility--could just check that the argument to the renderer is a literal type. You might have to be careful there, though, because a complex type (one that has keys which themselves are objects of community-defined types) might have Z18s, Z7s, etc. nested inside.