A complicating factor in the suggestions here is that VisualEditor doesn't actually have a preview phase (because it's a WYSIWYG editor, and so it's its own preview). The question then becomes when is an appropriate time to show them.

The Scribunto mw.addWarning function looks like it winds up calling ParserOutput->addWarningMsg to store the messages, which EditPage eventually gathers in getPreviewText and displays. Presumably we could request this information anyway from the stashed HTML before saving, in some sort of "the following warnings were seen" and send the user back from the save dialog if they want to deal with them. Sounds very unfriendly though -- and we'd need to filter out that "this is a preview" warning otherwise we'd be pointlessly showing it on every single edit.

Perhaps better would be if we could expose this in e.g. the APIs that Citoid calls to render the citation-templates, because then we'd be able to actually locate the issue within that dialog so they could see it's an issue with the specific citation they're adding right then.

(Separate issue: whether the VE-based 2017 wikitext editor, which does have a preview phase, shows these messages.)

The question then becomes when is an appropriate time to show them.

Given how mw.addWarning generally functions today and how VE functions today, I'd roughly expect it to be landing wherever edit notices are now in VE (which I think has been worked recently). The parallel here is that these are roughly in the same location in the non-VE wikitext editors as well.

Perhaps better would be if we could expose this in e.g. the APIs that Citoid calls to render the citation-templates, because then we'd be able to actually locate the issue within that dialog so they could see it's an issue with the specific citation they're adding right then.

The warnings the citation modules generate using mw.addWarning are not useful for this purpose: it's a "hey dummy, there are issues with the citations writ large, even if you don't see them where you're working" rather than a specific "this is the issue, and this is the issue, and this is the issue with any given citation" - the example in the task description is a different warning coming from Scribunto I believe. Same use of mw.addWarning I think.

The citation module also outputs the specific errors/maintenance messages directly in the context of the reference, which should already be displaying in the insertion popup as well as on the displayed canvas (ignoring questions of the subset of messages hidden by TemplateStyles). See:

Aside: I suspect it would be a consensus user view that mw.addWarning's behavior on this point has never been all that great besides for this general purpose and that most people would prefer to see the warning inline, but changing that function directly would likely cause some consternation for even more suboptimal placement inline, so you'd be looking at a new mw.addInlineWarning. The rough equivalent of such an inline preview warning message does exist as the preview warning template. As the implementation of such a function is trivial, at best you're winning "wikis don't have to repeat themselves", less additional customization specific wikis may wish the Scribunto function had but probably won't.

VE edit notices show up in this side-popup when you start editing a page:

(This is how VE has handled it for a very long time. The recent change to edit notices was to make the mobile editor(s) show edit notices rather than just silently discarding them.)

The main drawback to showing them here is that it's a start-of-edit display, so you'd be shown existing warnings on the page but not notified if your edit causes new warnings to appear. Although, as you said, the warnings are sort of a vague "something's not right, but probably not wrong enough that the page is broken", and we only show them in source mode to people who actually view a preview anyway, so this might be an acceptable outcome.

Yeah, that's what I remembered. There is T212848: Make edit notices more visible in Visual Editor already which is perhaps relevant to that question.

In T349851#9286625, @Izno wrote:

Aside: I suspect it would be a consensus user view that mw.addWarning's behavior on this point has never been all that great besides for this general purpose and that most people would prefer to see the warning inline, but changing that function directly would likely cause some consternation for even more suboptimal placement inline, so you'd be looking at a new mw.addInlineWarning. The rough equivalent of such an inline preview warning message does exist as the preview warning template. As the implementation of such a function is trivial, at best you're winning "wikis don't have to repeat themselves", less additional customization specific wikis may wish the Scribunto function had but probably won't.

This is more so the point about how Citation/CS1 module generates those warnings, not about how useful mw.addWarning is. I use it in some modules for more detailed, high level errors that point to where the error originates from. No one forces Citation/CS1 to implement them in a way where they are borderline useless.

Also, inline preview warnings rely on weird hackery behaviours ({{REVISIONID}} magic word), do not work reliably well in all environments (for example, previewing templates usually fails to show them) and can probably be substituted into the page code on accident. I’d argue the idea with mw.addInlineWarning is actually very good for those reasons.