Tables are problematic yes and this is a long standing problem but there is no silver bullet I can see. We have been aware this is a problem since 2011, but a big part of this requires the work of editors. Part of the problem is tables are used for other layouts and it's impossible to differentiate these. What would be helpful (and what has worked well in the past) is to point to specific widely used templates in articles and think about smaller problems in isolation.

When the reader taps on a table rotate the screen and show the table in fullscreen.

That sounds unexpected and not a very friendly user experience. From a technical pov this would also be tricky - as it would require rotating the entire screen 90 degrees on behalf of the user to get the right effect.

When the table is displayed in rotated-screen-fullscreen show a large horizontal scrollbar at the bottom if some columns are still cut off

If we forget the rotated screen part, this is the status quo. A horizontal scrollbar should already appear on tables and if it doesn't thats a bug.

Additionally there could be a way to "prioritize"/tag columns so that if columns are cut off on

This requires editorial support which has been the biggest challenge in making editor content mobile friendly. There's some good discussion on https://www.mediawiki.org/wiki/Recommendations_for_mobile_friendly_articles_on_Wikimedia_wikis#Avoid_tables_for_anything_except_data

Thanks for the input and the related issue.
@TheDJ commented "4. Personally I do think that having some sort of 'make this table fullscreen' option is required. [...]" there.
I think my suggestion above would be the most effective implementation of such a fullscreen option in terms of eventual usefulness.
This fullscreen-rotate-screen option is already implemented in many apps including the YouTube app which rotates the screen for a fullscreen view.

Part of the problem is tables are used for other layouts and it's impossible to differentiate these.

Part of the problem is tables are used for other layouts and it's impossible to differentiate these. What would be helpful (and what has worked well in the past) is to point to specific widely used templates in articles and think about smaller problems in isolation.

Maybe the "tap on table to un/make it fullscreen" could be made an option to tables which is enabled by default but could be disabled by setting e.g. {| class="no-rotate" on the table so that it could be added manually for exceptions.

That sounds unexpected and not a very friendly user experience.

It's already implemented in many popular apps as explained above so people should be fairly accustomed to it. It could be undone fast and easily with another tap or by taping a button that appears in that view. Also, as in the issue, there should be a small image in a corner that indicates that the table has to be taped to be viewed better / that the screen will rotate for a fullscreen view when it is taped.

Technical implementation

From a technical pov this would also be tricky - as it would require rotating the entire screen 90 degrees on behalf of the user to get the right effect.

Maybe a technical implementation would require tasks in external software and standards. Maybe transform: rotate could be used (e.g. see this and the next link). The proper way would be using the Orientation Lock API. The latter is still experimental and requires the web page to be in full-screen mode. See "Locking to a specific orientation and unlocking" here. Here is a demo which didn't work in the Firefox Focus mobile browser but could set the full-screen mode.

If we forget the rotated screen part, this is the status quo. A horizontal scrollbar should already appear on tables and if it doesn't thats a bug.

No, it's not a large scrollbar and it's only at the bottom of the table, not at the bottom of the field of view.

Additionally there could be a way to "prioritize"/tag columns so that if columns are cut off on

This requires editorial support which has been the biggest challenge in making editor content mobile friendly.

It would not be necessary but only be an additional improvement over the suggested fullscreen-rotate solution. Imo it wouldn't make much sense as a standalone solution without first increasing the field of view via the fullscreen-rotate solution.

There's some good discussion on https://www.mediawiki.org/wiki/Recommendations_for_mobile_friendly_articles_on_Wikimedia_wikis#Avoid_tables_for_anything_except_data

Thanks for the relevant link. Imo the "Avoid tables for anything except data" recommendation there is mostly due to technical barriers which imo should be solved (instead and asap due to increasing access via mobile browsers).

That's the same underlying problem.

@Aklapper And? Even if that was the case and I don't see why that would be the case, then it only means that this issue depends on the other problem being solved first. That doesn't make it the same issue. And the one you specified is closed as duplicate to begin with so it would need to be a duplicate of T361737 and it clearly isn't. You could make it a subtask or something but I don't see why that would be reasonable – this is a separate issue even if it did depend on the problem of "elements extend[ing] beyond the content area and overlap[ping] sticky page tools" being solved first.

@Prototyperspective More subtasks which serve no purpose are not welcome if a subtask requires zero additional code work but gets fully solved by its parent task

@Aklapper I think that's a bit over the top. There is a valid feature request in here for further improving the way tables work on mobile. While full screen zoomable tables are not 'easy' to implement, they are not impossible either. It's not very likely to happen and I don't see anyone spending time on them any time soon, but it's not the same as 'the thing scrolls (in a hardly discoverable way)'.