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 @Mormegil, @Jdlrobson and @Pols12 for the digging, patch provided.

@egardner I think we are better off also putting an equivalent to the current @ooui-unit variable as token into Codex, first idea sizing-unit or more limited font-sizing-unit.
I think, not only for the OOUI use case, but for themability that could be a good offering too.

Thanks for the long comment @matmarex! Agreeing with most of it, what you've shared above was also my concern (before looking at the comment above) for the approach with Select. We would expand in the currently best scenario overlong labels only in tooltips. Which is a usability issue, that we should prevent.
I could even see dark UX patterns with ellipsis only even though not the best ones out there.

In addition to above comment, while AT users still have access to the full label, touch screen users wouldn't with a browser default tooltip only solution.

I see one usability concern with ellipsis in Select as is. You can't see what the full label of the Select is anywhere anymore. I'm not convinced that we're taking away a good boundary for designers/developers to actually think about a proper (internationalized) label firsthand. @bmartinezcalvo

Great, given the feedback by the two of you, I'd propose to go with our minimum font-size of 12px equivalent as middle ground (with the only slightly increased padding), also to not disturb users with too much change without community liasions support.
We might revisit this in the future, while already be closer (and possibly also have a “compact” or “dense” variant) to the default Table layout.