I imagine the most feasible thing here would be to update the gadget extension to support community managed icon packs that gadgets and scripts can use. Editors with the appropriate user right could edit MediaWiki:Gadget-icon-definitions to define a icon module name and list icons.

In T311099#8107270, @Jdlrobson wrote:

I imagine the most feasible thing here would be to update the gadget extension to support community managed icon packs that gadgets and scripts can use. Editors with the appropriate user right could edit MediaWiki:Gadget-icon-definitions to define a icon module name and list icons.

That would work for gadgets, but as a script developer I should be able to load an icon without needing for the community to define a gadget that loads an icon, since defining a gadget means that metadata about the gadget module is added to all page views of all viewers

A script developer could request/use one of those icon packs managed in the definitions file. If any script can arbitrarily load icons, I'd be concerned that this might result in shipping several versions of the same icons when multiple scripts are installed.

I don't think allowing any developer to generate any arbitrary icon pack is a good idea so I think some kind of collaboration on what icon packs make sense would be the best outcome here. We do a similar thing for gadgets that share the same files. Perhaps we could provide some default modules to ease the burden here (perhaps on meta wiki?).

In T311099#8130427, @Jdlrobson wrote:

A script developer could request/use one of those icon packs managed in the definitions file. If any script can arbitrarily load icons, I'd be concerned that this might result in shipping several versions of the same icons when multiple scripts are installed.

I don't think allowing any developer to generate any arbitrary icon pack is a good idea so I think some kind of collaboration on what icon packs make sense would be the best outcome here. We do a similar thing for gadgets that share the same files. Perhaps we could provide some default modules to ease the burden here (perhaps on meta wiki?).

"I don't think allowing any developer to generate any arbitrary icon pack is a good idea" why not? While multiple copies of the same icon might need to be used, depending on how icons are retrieved, if this is impossible then user scripts will lack a way to migrate from OOUI properly. Defining modules that provide icons would result in more metadata for the module registry, for everyone, and is (in my view) one of the drawbacks for the OOUI icon pack system. What is the point for having such a big library of icons in codex if they cannot all be used?

"I don't think allowing any developer to generate any arbitrary icon pack is a good idea" why not?

Each icon pack would be a ResourceLoader module and T225842 has not been implemented so each icon pack would bloat the registry overhead in the startup module and impact performance for everyone.

What is the point for having such a big library of icons in codex if they cannot all be used?

I didn't say it wouldn't be used. I just said we should be careful about how we expose them. OOUI has multiple icon packs. Presumably, worse case we could do the same. I think having an icon capability in the MediaWiki:Gadgets-definition is probably the best case as gadgets would include icons within their own definition.

In T311099#8131864, @Jdlrobson wrote:

"I don't think allowing any developer to generate any arbitrary icon pack is a good idea" why not?

Each icon pack would be a ResourceLoader module and T225842 has not been implemented so each icon pack would bloat the registry overhead in the startup module and impact performance for everyone.

This was exactly my thought, we should not need to rely on modules to load icons because icon packs would limit the options or the packs would need to include all icons, meaning that too much would be downloaded. This is why I suggested adding an api endpoint instead. Yes, it would be less efficiently cached, but it would avoid the overhead of bloating the startup registry. Gadgets could still load the icons directly, but user scripts would also have a way to do so.

Some thoughts about how script authors might handle this currently; I was just asked about this and found that copying the icon svg into my user script worked as a hack:
https://en.wikipedia.org/wiki/User:JSherman_(WMF)/revertrisk.js

Another hack would be to fetch the images from the toolforge cdn, eg:

const rootComponent = {
	template: `
	<p>
		<cdx-icon v-if="cdxIconInfo" :icon="cdxIconInfo" />
	</p>
	`,
	data: function () {
		return { cdxIconInfo: null };
	},
	methods: {
		fetchCdxIconInfo: function () {
			// return early if we already have the icon
			if ( this.cdxIconInfo ) {
				return;
			}
			fetch( 'https://tools-static.wmflabs.org/cdnjs/ajax/libs/codex-icons/1.0.1/images/info.svg' )
				.then( function ( response ) {
					return response.text();
				} )
				.then( function ( iconData ) {
					this.cdxIconInfo = iconData;
				}.bind( this ) );
		}
	},
	mounted: function () {
		this.fetchCdxIconInfo();
	}
};

This method works okay too, but it seems like it could result in quite a few extra page requests; also I'm not validating what text is coming back from the cdn, which seems like a problem.

Thinking through a non-hacky way: From the script dev ux side, having an api that allowed piping in multiple icon identifiers and sent back a batch of icons would be handy. What if such an api were implemented in the gadgets extension? Maybe wrap that in a utility that populates local storage (or a global, or something) so that multiple gadgets don't re-request the same assets repeatedly?