Note that it would probably break backward compatibility slightly if we do it for xwiki/2.1 so we’d need to decide if we accept that breakage or if we want it in a new xwiki/2.2 syntax.
There must be no wrapping <span class="wikiexternallink">
There must be no wrapping <p>
While this could create the impression that this is easy to implement, I think this is actually quite difficult to properly implement, in particular:
CKEditor 4 has no support for nesting block content in links (I have not checked CKEditor 5).
XWiki syntax parsing only supports this because we are using a separate parser to parse the link label.
WikiModel also doesn’t support this kind of nesting, thus adapting the XHTML 5 parser or also properly parsing this right in the parser for XWiki syntax will require non-trivial changes in WikiModel. In particular, parsing a link currently automatically triggers the opening of a paragraph even though it should only do that if the link contains just phrasing content (which is not known at that point).
Our body filter in HTMLCleaner would need to be adjusted to not to wrap <a> in a <p>-tag (in HTML 5) - that’s relatively easy, though, apart from the fact that we cannot simply use the same for HTML 4 and HTML 5.
It is not clear to me how we should render this in XHTML 1.0 or any other syntax we support (like LaTeX).
Supporting this syntax just for images seems way easier to me as in HTML, WikiModel and Rendering Listener API we just handle this as figure/figure caption and not as (image) reference.
Actually this is not really supported. It’s just that we don’t do anything special to handle standalone blocks inside reference labels. We have a jira issue for this, to provide valid XDOM. Normally we should have stripped the standalone blocks.
Sure, that’s ok with me too FTM (until we want to support it), I didn’t see it in the 4 options that you provided above. Provided users can’t enter standalone blocks in references when using the wysiwyg editor.