I'm trying to clean up the tasks around this topic. It's time for another round of merging duplicates.

My proposal is:

1. This one (T121470) should probably remain as the main reference point for global templates, modules, and gadgets, simply because it appears to be linked to from so many places (correct me if I'm wrong). Duplicates:
2. There should be one subtask for global gadgets. Probably T22153: Implement global gadgets (WMF-wide)
   1. Duplicates:
      1. T153263: Allow easier downloading of userscripts/gadgets (from enwiki and such)
   2. Subtasks:
      1. T117540: Introduce global registry for gadget module identifiers
3. There should be one subtask for global templates and modules, because they are mostly similar (but see below). It can be T52329: We need a common repository for Scribunto modules and templates.
4. The common task for templates and modules should have further subtasks for things that different for templates and for modules. Examples:
   1. Modules:
      1. T135845: Convert any module as central or centralisable
      2. T41610: Scribunto should support global module invocations
   2. Templates:
      1. T3126: Interwiki templates
      2. T6547: Support crosswiki template inclusion (transclusion => interwiki templates, etc.)
5. I'm not sure what to do with even more generic tasks, such as these:
   1. T66475: Make crosswiki bits and pieces truly global (tracking) - This task (T121470) can probably be its subtask.
   2. T11890: Reasonably efficient interwiki transclusion
   3. T91162: RFC: Shadow namespaces - this should probably a blocker for T121470 if @Legoktm and other relevant people still think that it's the way forward as the internal technical solution.

This list is probably not complete, but it's a beginning.

Furthermore, I suggest to decline the tasks that ask for global user scripts. We already have global personal Common.js, and (hacky) cross-wiki loading of user scripts. So it's enough to have global gadgets at some future point, and when this becomes possible, if anyone wants to make a user script global, it won't be too hard to convert it into a gadget and make it global.

(yet another example)
I want to fix https://he.wikipedia.org/wiki/Module:Infobox_gene to use getEntity instead of getEntityObject which is legacy alias, it is cloned from https://en.wikipedia.org/wiki/Module:Infobox_gene which is protected.
What is the best way to achieve it?

1. Ask sysop permissions /templateeditor permissions in enwiki, fix it there, port it back to hewiki, hope that 20 other wikis will update their forks as well?
2. Update hewiki and let enwiki pull back the changes, ope that 20 other wikis will update their forks as well?
3. Split the module to logic that is common to all wikis, put it in shared repo, and fix it there

@BoldLuis: This is not a forum; please also see https://www.mediawiki.org/wiki/Bug_management/Phabricator_etiquette if you'd like to be active here. Thanks!

I tried to help to fix the bug with ideas.

From the source you leaded to me :

Criticize ideas, A healthy amount of constructive criticism and vibrant debate helps to improve our software and is encouraged.

I am going to try to help to fix bugs. This is a global bug an need goal fixes in different projects. Thanks for your understanding 🙏

A related proposal from the Community Wishlist survey 2022.

A related proposal from the Community Wishlist survey 2022.

For the record, that one was archived in favor of https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2022/Larger_suggestions/Global_templates_and_modules

In T121470#5638768, @Tgr wrote:

Without raw you get back a HTML blob rendered by a different parser, there is no end to the exciting bugs that could cause (local interface changes would get ignored, for example; links would be blue or red based on whether they exist on the templatecommons wiki). If you prefix all template names with raw:central_wiki_name, they won't work on the central wiki itself (I guess that would be not super hard to fix). It will also break cache invalidation and maybe performance, plus Parsoid would have to be updated to support it. Functionally, this is more or less what the shadow namespace proposal was aiming at (but it was a wishlist item and wasn't finished within the year, so I imagine there must be much more complexity to it than I can see at a glance).

For what it's worth, I created wikitemplates.org as a demo wiki for the Wikitemplates proposal, did some experiments with the "raw" prefix and drafted some best practices. It seems the templates do work at the central wiki itself.

In T121470#5638890, @Tgr wrote:

Well, a bot has been written with very much the same mindset.

Unfortunately that bot has been broken for over a year now. :-(

See Synchronizer for a semi-automated tool for solving or mitigating this issue.

I wonder if we can actually start somewhere like with Fandom's Dev Wiki. Almost the entire contents of that wiki should be compatible with Wikimedia's content license. If we can build a template and module repository that Wikimedia (and other projects) can use, then we can open the door to global templates. It would allow for templates ported to be deletable unless if they are highly used on a project.

Clicking "edit" on a global template or module should copy the contents of that global template or module so that it can be used. This implementation could actually be better because proxying will make things so much more efficient.