@Dbrant @JTannerWMF Thanks for picking this up! What would/could DST do to make this workable.
From my POV apps and PCS are not using wikimedia-ui-base as dependency, just an outdated copy. We can proceed with sunsetting it.
The transformation to Codex is as simple as updating it itself.
A bigger question is if the apps would benefit from Codex tokens as dependency with an export format as shown in proof-of-concept in https://gerrit.wikimedia.org/r/c/design/codex/+/856036 on task T327200: [Spike] Explore tokens export to mobile platforms Android and iOS

A previous small amendment similar was T343239: Amend Wikimedia Design System`#d33` to `#d73333` for an example of full impact on Wikimedia deployed software.

From an accessibility perspective, we need to ensure that the change in DOM (specifically with the 'show'/'hide' functionality) is exposed to assistive technology (AT). From this perspective with its parent>child connection and also from a usability POV with problematic move of all elements underneath a suddenly showing component, I'd advise to strongly emphasize the "or other" version.
For technical clarification: All nodes that aren't part of the DOM/accessibility tree after page load have to be specifically marked up with aria-hidden, aria-live and role="alert" or role="status".
The correct exposure of "and other" in AT would be an acceptance criteria for me to resolve this task successfully.

Not in anyways continued with Codex being focus of Wikimedia Foundation now.

Not going to be proceeded with focus of Codex

Not going to happen anymore with Codex Wikimedia Foundations' focus.

Sadly for all the work provided by @gabriel-wmde, we won't proceed with this and focus our energies on Codex instead. Thanks nonetheless! <3

In T368082#9911110, @Esanders wrote:

I've never really understood the hidden file standard (leading .) so happy to go without it. Other tools are inconsistent, so I don't think it matters too much which we pick:

• .eslintrc.json
• .stylelintrc.json
• .bananaconfig.json
• tsconf.json
• package.json
• bundlesize.config.json

First patch is only about SVGO optimization similar to the one already provided above in order to have clean separation of steps.

In T256190#9876030, @Ladsgroup wrote:

@Volker_E I used your powered by icon, do you want to work on and build a small version of wikimedia project SVG too? If we can reduce size of both even further, that'd be nice.

@Jdlrobson I think it's better to merge this into T367095: OOUI dark mode bug fixes post-0.50.0 release

In T367103#9877618, @Jdlrobson wrote:

After investigating this some more, it transpired the issue was a longstanding issue that was only causing an issue in Monobook. We have fixed the issue by making sure these are wrapped in brackets to force LESS to calculate it correctly.

According to @Catrope the problem here is "MW is stuck on a PHP port of an older version unfortunately".

• Less.js PHP port

Thanks @Od1n for the further information. Reason for calc() in original Codex definition was, that we aimed to provide possible Codex theme authors with the possibility to use not only pixel values, but also em values for breakpoints, as those have been stated as best practices in CSS for responsive design from some authors in the past. And then we'd end up mixing (giving fictitious numbers here): calc( 30em - 1px ).

Just for completion, an issue in the original implementation of Codex carrying MediaWiki skin variables was uncovered by the work here: T367103: Media queries using max width breakpoints are not working in Monobook and Fallback skin

To be clear, for users of low-vision the newly chosen color would mean that information is inaccessible. I would suggest a different choice, like a much darker color and add additional styling.
From your example of “Hawkeye7”, it uses italic font styling.

In T349793#9873038, @TheDJ wrote:

Related, noticed that Echo defines custom breakpoint ‘@specialpage-hd-width: 982px;’

After T337954 we might now be able to replace that as well

Thanks @Izno, @Mormegil, @Jdlrobson and @Pols12 for the digging, patch provided.