We actually have the icon sources in the public access Figma file, where we should put all non-code specific comments.

From my personal experience, I have not seen ids as specifically helpful as the creation overhead for them in code outweighs the benefits.
Mind, that our Codex icons all are exported by Figma, where we already rely on third party software for the code. We're (@bmartinezcalvo @Sarai-WMDE and myself) are currently attempting to add a Figma plugin following the shared Wikimedia SVG guidelines for initial export there. In any case most SVG code documentation would have to be correctly identified and added manually later on, would have to be re-added every time an icon changes. With all that, I wouldn't bother going down that route.

The other point about recent SVGO change resulting in slightly bigger (few bytes per icon) optimized output digged up by @thiemowmde has an actionable point from my perspective.
Even though we've got a great icons overview page, it's sometimes helpful for a quick design or icon amendment to start with Codex raw files, specifically for people who are not closely involved in design everyday.
The change is providing popular software like Inkscape or Adobe Illustrator with undistorted icons for their years old SVG render libs, therefore I'd suggest relying on default SVGO coding Wikimedia conventions including the slightly bigger raw files and add the plugins for the smaller path output back to the transform. (I'd also accept the slightly bigger defaults in OOUI and change only, if at all, the dist SVGO build script).

Change 755847 had a related patch set uploaded (by VolkerE; author: VolkerE):

[design/codex@main] build, icons: Optimize raw file SVGO config further and re-crush icons

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

Sketch software before	after patch with better backwards-compatible SVGO output

(sorry, was only darkgrey background available)
Example: https://gerrit.wikimedia.org/r/c/design/codex/+/755847/1/packages/icons/src/images/alert.svg – 4 bytes more uncompressed

Change 755847 merged by jenkins-bot:

[design/codex@main] build, icons: Optimize raw file SVGO config further and re-crush icons

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

In T299738#7639181, @Volker_E wrote:

From my personal experience, I have not seen ids as specifically helpful as the creation overhead for them in code outweighs the benefits.

What do you think about situations where a path has to have an ID because it's reused? In that situation, would you want the ID to be something human-readable, or should it just be 'a', 'b', etc?

and add the plugins for the smaller path output back to the transform

Yes, let's do that. Can you identify what those plugins are, and how they change the output?

In T299738#7649885, @Catrope wrote:

In T299738#7639181, @Volker_E wrote:

From my personal experience, I have not seen ids as specifically helpful as the creation overhead for them in code outweighs the benefits.

What do you think about situations where a path has to have an ID because it's reused? In that situation, would you want the ID to be something human-readable, or should it just be 'a', 'b', etc?

In our simple, small canvas icon SVGs, we don't have and won't in future need to deal a whole lot (currently 5 out of 200+ icons) with using transforms.
Among the most advanced examples is currently 'settings.svg':

<g transform="translate(10 10)">
	<path id="a" d="M1.5-10h-3l-1 6.5h5m0 7h-5l1 6.5h3"/>
	<use xlink:href="#a" transform="rotate(45)"/>
	<use xlink:href="#a" transform="rotate(90)"/>
	<use xlink:href="#a" transform="rotate(135)"/>
</g>

So only one id equal a is currently needed in all our icons collection for transform. I don't see a real win here for better human readability.

and add the plugins for the smaller path output back to the transform

Yes, let's do that. Can you identify what those plugins are, and how they change the output?

The main problem I've tried to clarify is use a DRY approach of reusing the default SVGO config in 'svgTransform.js' but loadConfig didn't provide in my own attempts.
I've been thinking of loading default config file and overriding several plugins, but maybe it's just a matter of turning the script loading order on the head (put general minification before 'svgTransform'). Inputs welcome!

Change 758547 had a related patch set uploaded (by VolkerE; author: VolkerE):

[design/codex@main] build, icons: Amend Vite transform SVG build step to further optimize

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

Change 758547 merged by jenkins-bot:

[design/codex@main] build, icons: Amend Vite transform SVG build step to further optimize

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