I experimented a bit and the best combination of HTML + CSS I can find so far goes like this:

<ol class="references">
<li><span class="mw-ref-item-number">1.&nbsp;</span><span class="mw-cite-backlink">…</span>
<span class="reference-text">…</span>
</li>
</ol>

<style>
.references {
	list-style: none;
	margin-left: 3.2em;
	padding: 0;
}
.references li {
	text-indent: -3.2em;
}
.mw-ref-item-number {
	display: inline-block;
	min-width: 3.2em;
	text-align: end;
	vertical-align: top;
}
</style>

Relevant details:

• The indention makes sure that long footnotes still wrap as they do now.
• I had to turn a space into a non-breaking space and make it part of the number. This is to make sure that all alignment happens after this space, right before the backlink – which is where it is now.
• That should work with both numbered <ol> as well as bulletpoint <ul>. I believe we are free to choose what semantially makes more sense.

Something like the proposed would probably sound as duplicated numbers to accessibility agents, which would read out the list item's number and then separately the generated number (and well it would be a pair of duplicated numbers for sighted users also so something would have to be done about that).

I think what probably could be done on that point is something closer to <li data-localized-number="n"></li> (<- bikeshed name since it's not just l10n - we want to support non-Latin scripts like the Greek letter notes on English wikis here) and then use CSS which is still slightly similar to what Parsoid et al do but which isn't, something like .mw-references li::marker { content: attr(data-localized-number); } (attr() is supported at baseline - in fact what is relatively unsupported is Parsoid's ::marker selector - thanks Safari - but this has a graceful fallback to Arabian numerals I suppose?).

Then you don't have to fight with setting up the list item as a grid of whatever sort.

even in the absence of CSS or browser support. (and also copy-paste)

I alluded to it above but I don't think this is possible in your version since you'll end up with duplicate digits? Well, in general the span added kind of adds quite a chunk of HTML to the page too, and references get beefy already. (Maybe this is about the same for the suggested.)

Existing styles and gadgets should still work, or must be migrated.

What is this saying?

Still support multicolumn rendering.

I'm pretty sure this is referring to CSS columns. Your POC shouldn't impact that. You would have issues if this all is meant to refer to making the ol a grid (which I don't think it is but kind of riding the line of ambiguity in the description), since grids can't render down then sideways, only sideway then down.

In T383972#10490385, @Izno wrote:

Something like the proposed would probably sound as duplicated numbers to accessibility agents, which would read out the list item's number and then separately the generated number (and well it would be a pair of duplicated numbers for sighted users also so something would have to be done about that).

Agreed—this is the main reason I would consider switching to <ul> even though the question of semantics feels slightly ambiguous and I would have a slight preference to keep <ol> if potential duplication could be avoided.

I think what probably could be done on that point is something closer to <li data-localized-number="n">

We can consider it as an alternative—I tried something like this in visual editor (read more in T383681: Clean up visual editor reference list explicit numbering). Currently my feeling is that it solves the language support problem but at the cost of additional complexity, some drawbacks, and it degrades badly in the absence of CSS styling: if Western Arabic numerals appear in the reflist, they will no longer match the footnote marker symbols in the article.

Then you don't have to fight with setting up the list item as a grid of whatever sort.

+1 I would love a solution that avoids the grid issue entirely, let's keep the discussion going!

Existing styles and gadgets should still work, or must be migrated.

What is this saying?

For example, if we went with the <ul> suggestion then any CSS rules matching on ol.references (naïve global search) will need to be migrated, perhaps by adjusting the selector to .references

<ul> even though the question of semantics feels slightly ambiguous

If you feel an inclination to add numbers manually, that's a strong indication you should be using an ol.

T383681

I don't see where my suggested solution was tried, which is different enough to VE's status quo. The only similarity is that the status quo is targeting the marker with a change in content and then the presently inflexible counter method (which we are shooting not to use either way because of l10n and better access to "custom" digits). My suggestion still targets the marker with a content change but lets us set the numeral, which is what we want (of whatever flavor as designated in the configuration)?

To take the example block in the task description, just to be clear:

<li data-numeral="123">
  <!-- removed span -->
  <span class="backlinks">...</span>
  <span>Citation body...</span>
</li>

with CSS

.mw-references li::marker {
    content: attr(data-numeral) ". ";
}

renders nicely, with a sample:

And dodges the rest of the fussing AFAICS.