Just to be clear, this task is asking both for code changes (adding a proper rights hierarchy as part of the user permissions system in MW core) and documentation (documenting this new hierarchy system on MW.org)? It's not 100% clear that code changes are being asked for here.

There isn't really a hierarchy in user groups either. It only seems that way because '*' means "everyone" and 'user' means "all logged-in users", so it's very hard to have a user in any other group without also being in those two.

If one cannot read, they cannot do anything else.

Looking at the action API in core, someone without the 'read' right can still potentially log in, log out, create accounts, fetch CSRF tokens, fetch RSD information, submit CSP reports, access the help, access paraminfo (which is basically machine-readable help), and query AuthManager information. Some of those require rights other than 'read', e.g. "create accounts" needs the ability to create accounts, and "log in" might need the ability to auto-create accounts.

This project is selected for the Developer-Wishlist voting round and will be added to a MediaWiki page very soon. To the subscribers, or proposer of this task: please help modify the task description: add a brief summary (10-12 lines) of the problem that this proposal raises, topics discussed in the comments, and a proposed solution (if there is any yet). Remember to add a header with a title "Description," to your content. Please do so before February 5th, 12:00 pm UTC.

@TTO, yes I propose a code change as well as documentation. If you'd ask me for priorisation, I'd go for documentation first. I am pretty sure we will find peculiar dependencies during documentation, which I then propose to be fixed.
In addition, I propose to have a set of very basic rights which are the basis for other rights. Tuning such an extensive set of 80+ rights as we see it in MediaWiki is painful and failure prone. If, for example, I can rely on the fact that taking away read rights also completely takes away edit rights, or taking away the edit right would take away all modification rights, this would simplify the set up a lot, reduce accidential misconfigurations and make MediaWiki safer in the end.

Related: T156788: Improve support for read access restriction / access control

Some related notes regarding rights hierarchy:

• T213141: Separate edit and change permission in MediaWiki - currently, edit is needed for move, etc; the minimum right should be split into change, which is needed for both edit and move
• to move a page, a user needs to be able to edit the page at both the current title and new title [1]
• to move a category page, root user page, or file, a user needs both move and the respective move-categorypages/move-rootuserpages/movefile right [2]
• T212851: Confusing error for OAuth consumers with rollback but not edit grant - currently, edit is needed for rollback, which isn't well documented
• T241296: Separate block from editing and block from email - currently, blockemail does nothing if the user lacks block
• in AbuseFilter, abusefilter-modify-restricted does nothing without abusefilter-modify (and abusefilter-modify-global likewise does nothing without abusefilter-modify)
• in AbuseFilter, abusefilter-modify implicitly grants abusefilter-view-private

[1] https://gerrit.wikimedia.org/g/mediawiki/core/+/0c37a0a94a929e9c3465f02b537a1852a0028c75/includes/MovePage.php#122
[2] https://gerrit.wikimedia.org/g/mediawiki/core/+/0c37a0a94a929e9c3465f02b537a1852a0028c75/includes/Permissions/PermissionManager.php#758