@PDrouin-WMF and myself were discussing forthcoming on this discussion.
In a quick write-up we came up with these two mockups

sans-serif	serif

I'd also take the Material Design guideline in this context with a grain of salt. In their example it includes the “Page title”. That would translate to the article title in my understanding. If we agree on putting content first, I think the header bar can be sufficient at 48px.

To the concern of vertical alignment of buttons at higher font sizes:
The default size (16px) stays default

@bearND has already shared on major issue with multiple references side-by-side. We've additionally run into issues with line-height
CSS having negative consequences on line formatting (expanding distance) in the past. I'm not aware of an easy way to extend clickable area of links (mixing in display: inline-block with rendering consequences), that is free of side effects.
For sake of simplicity, I'd ignore the click target in this specific case with superlined text as they are only shortcuts to information that is anyways accessible at end of article.

In T227791#5341134, @Iniquity wrote:

In T227791#5341121, @Volker_E wrote:

@Iniquity 'info' is unresolvable at the time being, we are not changing this icon due to its wide usage while at the same time specific use case in a variety of VisualEditor dialogs. It is represented in this way to ensure recognizability on non-HiDPI screens and is advised not to be used. Instead use 'infoFilled'.

Hm, I understood. Then do we need to center it?

As it needs to be an even px value circle in a 20 x 20 px canvas, that won't be possible ;)

This task should be declined. The real bug is tackled in T228435.

@Nirzar What I've said before – yes, we could. We'd need the outlined bell & updated search icon on the 20x20px canvas, and the outlined user icon, which is planned as well? So it's only the latter missing here right now from my understanding

The alignment seems right(!) to me, as the icon is a search button trigger in Vector, while in OOUI it's an indication icon.

From design review earlier today, design team preference is with 3 votes pro option a) with Base90.

RecentChanges with all hovered frameless buttons in first proposal of Base90:

@Nirzar Sounds good, can go out into next weeks' OOUI release which would be in production train from Tue 30 August on. If there's urgent time sensitivity we could add them in an extra release before next Tue, which would land train next week.
In any case, we need the icons production-ready prepared as SVGs to proceed.

With added Base90 as :hover background color on frameless, agreed with @Prtksxna that it's too little to notice

@Iniquity 'info' is unresolvable at the time being, we are not changing this icon due to its wide usage while at the same time specific use case in a variety of VisualEditor dialogs. It is represented in this way to ensure recognizability on non-HiDPI screens and is advised not to be used. Instead use 'infoFilled'.
'reference' aligns with all other document related icons and is, if at all, to be changed altogether.

@Jdlrobson And here's the release…

“Creating” possibly to replace by “Designing”…

help-rtl position is a bug. Patch at https://gerrit.wikimedia.org/r/#/c/523729/

Indeed.

+1 for the blue outline/white background comment by Alex and that this ticket should only care about the non-circular icons. Both make sense.

PR 218 is merged and pushed to DSG server.

Thanks @Jdlrobson for reviewing quickly. One derived task has already been identified in T228100: Errors in mobile editor appear unstyled and are not obviously errors.

@nray If I could, I'd add another gold medal token for your dev notes. Excellent!

@Iniquity Those look very good already! Thanks to your input there's one more patch pending in OOUI reflecting padding amendment in Style Guide https://gerrit.wikimedia.org/r/#/c/oojs/ui/+/523337/

Design Style Guide part covered in https://github.com/wikimedia/WikimediaUI-Style-Guide/pull/218.

@Jdlrobson Yes, it is. It seems reasonable to have one tomorrow from my point of view. https://gerrit.wikimedia.org/r/#/projects/oojs/ui,dashboards/default

@Cntlsn Checkmark icon should actually be either Base0 or Green50 (with latter we tolerate a color contrast issue on this specific icon as the message should be self-explaining and the boundaries are sufficient.

We need clarification on a current, non-standard special treatment on MobileFrontend.
Both, errorbox and error styles receive a boxed appearance.
We should differentiate boxed and inline messages, as established in the Style Guide. That means, we need to ensure all instances of boxed error should be changed to errorbox when needed. @Jdlrobson your thoughts?

@Iniquity Thanks for the question. We're not changing them for the time being in core pages outside OOUI, as the most “common” box padding is 0.5em 1em. We might be able to pick this up after T220671.
A not-real example of current OOUI padding in core/Flow:

The success icon should be Green50 (green), not Accent50 (blue).

@Iniquity To what?

In T224070#5319441, @Jdlrobson wrote:

@Volker_E I'm using the bell icon in core and this is what I get... which seems a little big:

Is this the desired result?
Is the SVG asset in core up to date?

@Daimona I'm actually on it… ;)

The color choice above fails strongly color contrast requirements for WCAG 2.0 level AA. I'd recommend orienting on Design Style Guide recommendations for error messages (also covered in T127405).

@SerDIDG Hi, on iOS 11/12 Safari does show the right treatment:

Further examples where our current mix fails:

@Esanders “Distiniguish” as title seems inappropriate now.

@Cntlsn The positioning issues are wrong from my POV too (when looking at the provided screenshots). They seem originated in custom overrides.
You can have a look of the master state out of box at ProcessDialog in demos.

@leila Sorry, that this was still assigned to me, thought @bmansurov will pick this up after his switch to Research team.
The “News” cards were disregarded as it seemed unrealistic in conv with Dario to update that often. We kept that for next steps…

There has been a conversation “upstream” in the Design Style Guide repo, but status hasn't changed. It was de-prioritized. Seems like a stalled issue to me.
Editing RLP HTML is still possible…

In T225021#5322221, @matmarex wrote:

The close button also is now frameless. I can't tell if it is intentional but this also looks very poor, especially if the label is long.

@matmarex “Back” isn't always just labelled “back” as T226822#5322437 tells us.
In order to change back over to left-pointing arrow we need to make sure that

• this is meeting user expectations and not confusing (my guess is, that's fulfilled, but all of you know every dialog in VE better)
• we're consistently applying invisibleLabel
• we consider adding a title to the icon only action

In T220671#5292614, @Esanders wrote:

That's only a problem if you have to mix your ems with px. If you do everything in ems then everything will just scale for you. Yes the designs will scale slightly between the platforms, but not to a level that causes serious problems.