I noticed that the padding for each menu items for table cell got narrowed down. IMHO, it does not really look good.
The .ve-ui-tableLineContextItem-actionButton .oo-ui-buttonElement-button selector in ve.ui.TableLineContentItem.css sets padding: 0.5em; but that's getting over-ridden by something in OOUI; resetting it with !important doesn't work, but manually setting in the browser console does…
The misconception in how we are making our own lives harder than necessary is IMHO, that we maintain different logic in two themes, where Apex should be just a design (colors, gradients, icons differently) showcase without a lot of or any architectural differences at all.
It's a costly maintenance burden. I don't see the advantage of having the icons positioned in two ways in widgets or to have something like a SelectFileWidget have it's button bigger and left-aligned. When we're assuming that our primary theme is well-balanced from a UX perspective and thoroughly cross-browser & user research tested, why would we take a different approach in a widget in the second maintained theme?
The UX behaviour patterns should be at large the same (min-sizes of buttons, their position in the widget, icon position etc.). Things like a checkmark as option T87835 can stay in. Constructive buttons or differences of the ComboboxInputWidgets (a button appearance should indicate the boundary to the input) have to go.
Every developer can see that we give them all freedom, we don't have to celebrate it our own. Not unwillingly breaking stuff and ensuring cross-browser compatibility and mobile support of the library is already hard enough.
I'm fine to help here if we're clearly stating that MediaWiki theme is the one primary theme and leads the way when it comes to internal changes (only with good arguments) and Apex will follow those with probably some disruptive changes to the users of Monobook skin.