This could potentially be done as part of the epic T132072: Integrate page meta-data as a new content model revision slot for consistency and atomicity. There doesn't seem to be a task for "allow the concept of redirects for non-wikitext content types", though I thought there was.

Change #1172664 had a related patch set uploaded (by Jforrester; author: Jforrester):

[mediawiki/extensions/WikiLambda@master] [WIP] Allow ZObjects to be redirects to other ZObjects

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

Looking into this in detail, here's what I found out. Many of these things might be intended behavior, some other might be overlooks.

Overall, handling redirects is not straight-forward and it needs some product/engineering decisions. I've only tried redirects of three crucial types: functions, implementations and types.

Functions

When redirecting functions, they only run as expected when the keys are either local or set to the final function zid. So whatever testers or compositions are stored will stop working.

• Creation:
  • ✅ Create redirect using the API
  • ❌ Create redirect using the UI:
    • ❓is this intended behavior?
• Handling redirection: (E.g. Z27207 is a redirection to Z10000)
  • ✅ wiki/Z27207 redirects to wiki/Z10000
  • ❌ view/en/Z27207 does not redirect to view/en/Z10000
  • ❌ wiki/Z27207?uselang=en&action=edit does not redirect to wiki/Z10000?uselang=en&action=edit
    • ❓is this intended behavior?
• ❌ Function call to redirect fails with global keys, succeeds with local or final keys
  • ❌ {"Z1K1":"Z7","Z7K1":"Z27207","Z27207K1":"one", "Z27207K2": "two" }
  • ✅ {"Z1K1":"Z7","Z7K1":"Z27207","K1":"one", "K2": "two" }
  • ✅ {"Z1K1":"Z7","Z7K1":"Z27207","Z10000K1":"one", "Z10000K2": "two" }

Implementations

Redirected implementations work mostly well, although it could be the case that a redirected implementation is the only connected implementation in a function, in which case it runs well in the backend, but it does not appear anywhere in the function page. We might want to fix this and also show implementation redirects on the table. This will be difficult with current data structure, and we might want to store "redirectsto" relations in the wikilambda_zobject_join table.

• Creation:
  • ✅ Create redirect using the API
  • ❌ Create redirect using the UI
• Handling redirection (E.g. Z27208 is a redirection to Z10622)
  • ✅ wiki/Z27208 redirects to wiki/Z10622
  • ❌ view/en/Z27208 does not redirect to view/en/Z10622
  • ❌ wiki/Z27208?uselang=en&action=edit does not redirect to wiki/Z10622?uselang=en&action=edit
• Redirect implementation:
  • ✅ Function call works well with one redirect implementation (code or composition)
  • ❌ Redirect implementation does not appear in the implementations table

Type

Redirecting a type is generally a very bad idea, instances of these types don't work properly, for a similar reason than the function call keys with old zid; while the zid is double-dereferenced, the keys are unknown.
Functions that use these types stop working, as do their implementations and testers. There's no easy solution to this.

In T258915#11067806, @gengh wrote:

Looking into this in detail, here's what I found out. Many of these things might be intended behavior, some other might be overlooks.

Overall, handling redirects is not straight-forward and it needs some product/engineering decisions. I've only tried redirects of three crucial types: functions, implementations and types.

Functions

When redirecting functions, they only run as expected when the keys are either local or set to the final function zid. So whatever testers or compositions are stored will stop working.

• Creation:
  • ✅ Create redirect using the API
  • ❌ Create redirect using the UI:
    • ❓is this intended behavior?

Not specifically intended, but I thought we'd want to build a proper interface for adding/editing these, so that's fine, yes.

• Handling redirection: (E.g. Z27207 is a redirection to Z10000)
  • ✅ wiki/Z27207 redirects to wiki/Z10000
  • ❌ view/en/Z27207 does not redirect to view/en/Z10000

That's a bug that needs fixing, yes.

• ❌ wiki/Z27207?uselang=en&action=edit does not redirect to wiki/Z10000?uselang=en&action=edit
  • ❓is this intended behavior?

I think that's correct; otherwise you'd not be able to edit redirects (not that we give a good interface yet).

• ❌ Function call to redirect fails with global keys, succeeds with local or final keys
  • ❌ {"Z1K1":"Z7","Z7K1":"Z27207","Z27207K1":"one", "Z27207K2": "two" }

Ah, hmm, yes, key re-writing. Probably needed? Eurgh.

• ✅ {"Z1K1":"Z7","Z7K1":"Z27207","K1":"one", "K2": "two" }
• ✅ {"Z1K1":"Z7","Z7K1":"Z27207","Z10000K1":"one", "Z10000K2": "two" }

Implementations

Redirected implementations work mostly well, although it could be the case that a redirected implementation is the only connected implementation in a function, in which case it runs well in the backend, but it does not appear anywhere in the function page. We might want to fix this and also show implementation redirects on the table. This will be difficult with current data structure, and we might want to store "redirectsto" relations in the wikilambda_zobject_join table.

Yeah, sounds like we'd want to do that too.

• Creation:
  • ✅ Create redirect using the API
  • ❌ Create redirect using the UI

Ack, as above.

• Handling redirection (E.g. Z27208 is a redirection to Z10622)
  • ✅ wiki/Z27208 redirects to wiki/Z10622
  • ❌ view/en/Z27208 does not redirect to view/en/Z10622
  • ❌ wiki/Z27208?uselang=en&action=edit does not redirect to wiki/Z10622?uselang=en&action=edit

Ack, as above.

• Redirect implementation:
  • ✅ Function call works well with one redirect implementation (code or composition)
  • ❌ Redirect implementation does not appear in the implementations table

Yeah, I think that's a reasonable issue; the redirects are mostly for humans to get to the right place.

Type

Redirecting a type is generally a very bad idea, instances of these types don't work properly, for a similar reason than the function call keys with old zid; while the zid is double-dereferenced, the keys are unknown.
Functions that use these types stop working, as do their implementations and testers. There's no easy solution to this.

Agreed, let's not worry about this.