When a type has a key that points to itself, we should per default show a reference, not a literal

I will try to work on this since we had the same problem in the backend.

Can someone point me to the code in the UX that ends up turning the nominal into a literal? I think we can implement some similar functionality to what exists in the orchestrator.

The alternative would be to try to offload some of this work by actually calling the orchestrator, but I fear that that won't really solve the problem (not to mention the performance issues that such a solution would introduce).

Change 939357 had a related patch set uploaded (by Cory Massaro; author: Cory Massaro):

[mediawiki/extensions/WikiLambda@master] Do not create a generic type when type has already been seen; default to a Z9/Reference instead.

https://gerrit.wikimedia.org/r/939357

Change 939357 merged by jenkins-bot:

[mediawiki/extensions/WikiLambda@master] Do not create a generic type when type has already been seen; default to a Z9/Reference instead.

https://gerrit.wikimedia.org/r/939357

The function can now be called. It returns true (correctly) on this input:

{
  Z1K1: 'Z10528',
  Z10528K1: 'Z10529'
}

but false (arguably incorrect) on this one:

{
  Z1K1: 'Z10528',
  Z10528K1: {
    Z1K1: 'Z10528',
    Z10528K1: 'Z10529'
  }
}

In T336719#9028290, @cmassaro wrote:

The function can now be called. It returns true (correctly) on this input:

{
  Z1K1: 'Z10528',
  Z10528K1: 'Z10529'
}

but false (arguably incorrect) on this one:

{
  Z1K1: 'Z10528',
  Z10528K1: {
    Z1K1: 'Z10528',
    Z10528K1: 'Z10529'
  }
}

Any state that is easily triggerable through the front-end seems to return the correct behavior, see the screenshots:

The one way I can trigger the wrong behavior is like the following:

I think that's good enough for now.

I want to file a follow up task, but then close this one, to further improve the behavior. But it doesn't break, so that is awesome! Thank you!