It appears we lack a common understanding of where local and global keys can appropriately occur, and also lack code consistency in the support for local and global keys. This can cause unexpected bugs and time spent diagnosing and fixing them. It can also require time for each developer to investigate and understand what needs to be supported. We need greater clarity and precise documentation about this.

Illustration: Recently it was necessary to modify a front end JavaScript utility (getValueFromCanonicalZMap) that handles ZTypedPair instances, so as to allow for either local (K1 and K2) or global (Z882K1 and Z882K2) keys. (I'm referring to the keys for "first element" and "second element", not keys that are used inside the Z1K1.) The ZPair type processed by this utility is transient, not persistent.

This quote from function model page indicates that a local key is appropriate in this setting: "The main use case for Local Keys is when a Z8/Function or Z4/Type is being created on the fly, and thus cannot have Global Keys because the created Z8/Function or Z4/Type itself is not persistent." It was also necessary to do new work on ZObjectFactory::create() because it expected global keys. Currently, it still changes local keys in the input (K1 and K2, which were placed there by the orchestrator, and are appropriately local) to global keys in its output (Z882K1 and Z882K2), at least in some cases. Let's consider whether that behavior should change.

Questions: Should we move away from this ambiguity, so that eventually we only need to support local keys in this situation? More generally, should we have a completely unique canonical form for each ZObject, or allow for certain variants in the canonical form?

See also: T313880 and its patches.

Note: regarding getValueFromCanonicalZMap, it's also present in function-schemata, and currently only supports local keys. It's my impression that function-schemata functions generally support less variation with respect to local versus global keys.
Note: See also engineering meeting notes for August 4, 2022.