I'd suggest to reopen this specific task for one reason:
While Codex is used in more and more places, it's still minority against OOUI interfaces. And specifically with error/destructive colors which are signals for some of the most important user decisions, we shouldn't confuse users with different shades facing such decisions.
For minimizing confusion and reducing possible user support issues, I'd suggest to align OOUI with these amended colors.

@lwatson Very nice IMHO and a real interface improvment, thanks! :)
Curious what others think…

@DTorsani-WMF One thing I've been musing together with @lwatson about is the redundancy (and prominence) of the labels per Card.
In my opinion the Card has here a tougher stand vs a tabular presentation.
I'd in any case consider to remove the labels from all but the first and last card per view to focus more on content and reduce redundancy/noise. What's your take?

Comment I've provided already in the first encounter with the user-interface of the generally well-done component transformation: I'd reconsider using a ToggleButton for other possible components for the backport yes/no question.
Specifically as we're using a ToggleButton in the next screen and have it combined with a quiet progressive (also questionable) Cancel button.

@Djackson-ctr Which platform/browser is this screenshot from?

In T285592#8887113, @matmarex wrote:

(commenting here since you asked for my review on a couple of skin patches)

I like the changes in principle, since I can see them avoiding skin compatibility issues in the future, but they also have a huge potential to cause issues now – similar to the mobile VE problems already reported above, but in all of the non-default skins that don't get so much testing. I can't really commit to testing everything thoroughly myself; basically everything that displays a dialog or a popup can be affected. Maybe we could ask someone from the WMF QA team to test the non-default WMF-deployed skins at least, just this one?

Removing @ChandraPratap25 due to inactivity, I assume @GauriGupta is the Phab profile name connected to the patch author, correct? :)

This has been successfully resolved in latest piece of T332541: Replace mediawiki.ui variables with mediawiki.skin.variables.

In T349793#10181974, @Iniquity wrote:

Hi! :) Just to clarify, is this task not subject to breakpoint changes? Or does the menu appear according to new breakpoints?
T330532: [Design] Re-evaluate breakpoint for hiding page tools/toc to keep content width more consistent

As long as both, combination of icon and text, are fulfilling the majority of users' needs of being understandable as warning color and the special users' needs of being contrasty enough, that'd be good to go. In the past we've been compromising on a path between 1 & 2. With the color palette expansion, let's revisit this with new higher contrast yellows.

The request for amendment makes sense to me 👍🏻
As a note, link outlines are currently featuring Blue600 #4b77d6 in both, light and dark mode.

Coming later to the party, I've already been sharing some of the concern in a DST meeting before.

1. Most Wikimedia sibling logos were not made with a use case of this small canvas (20 x 20 dp) in mind. Normally a professional logo design would incorporate the question of the logo at a very small size with lesser details (if necessary) or a simpler logo overall
   1. The example of Wikidata logo might be misleading here, as it scales _ok_ on that canvas size on high definition displays and modern browsers (with latest SVG rendering libraries). A WikiSpecies or Wikisource logo might be completely broken at this size.

Example of logos at 20px width scaled down from wikimedia.org (only Wikiversity makes some sense to me):

2. This ask seems to also not take into account that not everyone is in the place of browsing the project on a high-definition display. If just 30% (no factual data, only for assumption) of users are seeing the interface on a 72 dpi display the downsampling of even the Wikidata logo gets really nasty.

Pixel tests (without surprises) were provided by @lwatson before releasing v0.13.0.

First a question out of curiosity: Do you prefer Chrome's Auto Dark Mode over Wikimedia Vector 2022's own optimized?
From what I understand about that proprietary feature, there is a possibility to fine-tune how it's applied in the settings. For example 'Enabled with selective inversion of non-image elements'

Sharing here as well for visibility, that we've put up a patch demo wiki with the proposed changes in Codex and OOUI applied: https://patchdemo.wmcloud.org/wikis/cfc43ebf1a/

@Jdlrobson Preface: The task scope has changed a few times. While I appreciate moving away from the checkbox hack, I'd like to share a small concern about the semantics of proposed details/summary specifically for the language button.
While details/summary seems compromisingly tolerable, it's semantically not the best choice in my opinion. A Codex MenuButton seems much more like a fitting choice for the language button. As it was published not earlier than v1.7.0 and June 2024, it wasn't available at the time of initially writing the task. We should reconsider the task acceptance criteria from my POV.

@ChandraPratap25 Please feel free to provide a patch!

I'm in general not a big fan of buttons who are changing their labels dynamically. It's an anti-pattern, a button should never change their label and rather have a clearer user feedback triggered if there's an indication to be made to users.
It's also problematic from an accessibility perspective, as there are no ways to indicate that loading change well to users of assistive technology.

Please also see previous attempt at T89069: Use buttons with spinners instead of loading overlays

There's an issue with the language button (a Codex fake button), it's partly already visible in production, but got worse with the color palette patch. Need to look closer to the fake button styles and the Vector implementation.