@Timeshifter: Assuming this task is about VisualEditor-Tables hence adding project tag so someone could find this task when searching for tasks under that project.

The example link at https://en.wikipedia.org/wiki/List_of_metropolitan_areas_by_population are two completely separate tables nested inside of a table.
Simplified structure, if you look at the source code:

<table>
  <tbody>
    <tr>
      <td>
        <table>
          <tbody>
            <tr>
              <th>Rank<br /></th>
            </tr>
            [...]
            <tr>
              <td>103<br /></td>
            </tr>
          </tbody>
        </table>
      </td>
      <td>
        <table>
          <tbody>
            <tr>
              <th>Metropolitan</th>
              <th>Country</th>
              <th>Continent</th>
              <th>Official population</th>
              <th>Year</th>
            </tr>
            [...]
          </tbody>
        </table>
      </td>
    </tr>
  </tbody>
</table>
<h2>See also</h2>

I'm wondering why one would use such broken designs and then expect things to somehow work.

VE can edit tables nested inside a table just fine. But it can't edit anything nested inside a transclusion, and in this case we have a table nested inside a transclusion.

matmarex. You are correct. I found a table using the old method of adding a separate row number column. It is not inside a transclusion. It is editable with the visual editor. See table partway down this user page:
*https://en.wikipedia.org/wiki/User:Timeshifter/Sandbox74

It is two tables nested side-by-side inside another table. But it is editable with the Visual Editor.

In T245277#5885422, @Aklapper wrote:

The example link at https://en.wikipedia.org/wiki/List_of_metropolitan_areas_by_population are two completely separate tables nested inside of a table.
Simplified structure, if you look at the source code:

...

I'm wondering why one would use such broken designs and then expect things to somehow work.

The table can be edited easily in wikitext. The problem is editing in the Visual Editor.

And the row number column works fine with the table. Even with various text sizes in one's browser. Also, {{Rank}} is a much easier method of adding a row number column than the previous method.

With {{Rank}} one can add a row number column by adding a single line of wikitext at the top of the table. And {{End}} at the bottom of the table. That single line of wikitext though has to be specific to that table. It is not intuitive like the proposed solution via this:
T42618. jquery.tablesorter: Add support for a "fixed" column of row numbers.

That is where I would hope more developer energy would be expended. I thought a solution had been found there. What is holding up its implementation?

In the meantime people are adding {{Rank}} to tables because that is basically all we have. Maybe the visual editor could be programmed to ignore that {{Rank}} template and not try to show the row number column. Then the Visual editor could edit the main table and not the row number table.

But the problem remains that the rows will misalign between the 2 tables if there is any laddering due to smaller screen sizes. The addition of class=nowrap prevents that, but makes for wide tables extending past the screen when using smaller screens or lower display resolutions.

The T42618 solution does not have that problem because there is only one table, and the row-number column is integrated into it.

In T245277#5888232, @Timeshifter wrote:

What is holding up its implementation?

You have not provided a patch yet. :) See https://www.mediawiki.org/wiki/Bug_management/Development_prioritization

In T245277#5888288, @Aklapper wrote:

In T245277#5888232, @Timeshifter wrote:

What is holding up its implementation?

You have not provided a patch yet. :) See https://www.mediawiki.org/wiki/Bug_management/Development_prioritization

Schnark and matmarex both provided patches years ago. I don't know why they are not being implemented. I would think by now that the problems blocking them years ago may have been fixed. I don't thing anybody is looking to see if that is true. In most cases I am not qualified to see if that is true. I know one reason is no longer true; the problem with old browser versions.

And adding class="sortable autonumber" was all that was needed for a solution provided by Yair Rand all the way back in 2014. So there are 3 patches. Surely by now, the problems blocking them have been solved? Or could be solved?