@Samwalton9-WMF I am curious what you think about removing AMC mode in favor of user-right based checks (given many of the changes moderator tool has been working on has promoted features from advanced mode to all logged in users).

I really like the idea of removing AMC mode, and it's something we made some progress towards in the past, promoting the Overflow menu to being accessible to all users after finding that new users weren't confused by it.

I'm less immediately enthusiastic about the idea of hiding some of these items based on user behaviour/rights, but not entirely against it. I know mobile is a constant battle of comprehensibility and feature parity. Some initial off-the-cuff thoughts:

• Some users want to use their sandbox right away, e.g. if they're at an editing event where they're going to create a new page, so hiding it behind 10 edits doesn't feel great.
• Some of the suggested criteria feel a little circular or self-defeating, like expecting a user to gain rollback rights without having had access to RecentChanges, or waiting to show watchlist until the user gains extended rights or uses the watchlist. We'd want to figure out how to identify that a user would find these features useful without setting the bar so high that they could never actually signal that interest. What if most of these were simply behind a "Has ever edited" flag, to separate readers from editors?
• Instead of having both a simplified and non-simplified view of RC/Watchlist/Contribs, I really think we should just spend the effort to make an interface that works for both new and experienced editors and use that for everyone. I know that's a bigger project than adjusting some permission logic, but it is something we're exploring with the PersonalDashboard 'Review Changes' module where we're designing a new mobile-first feed of edits that aims to both be comprehensible to a new editor and be useful to an experienced one. I had thought that we could potentially port over that design (or at least what we learn from it) in the future, if we find that it manages to do both effectively.
• I also wonder if we could do some more user testing of the sort we did for the Overflow menu. We assumed that that menu was potentially confusing or overwhelming, but when we sat down and did user tests with non-editors, they either didn't notice it or interpreted it correctly as "a list of things I probably don't need right now". Maybe some of these remaining links are the same, or could be taken one step further away from the user behind an extra menu, for example.

The logic for these decisions would also apply to desktop editors.

Does this mean that it doesn’t matter where a person edits, their edit level would reflect what they see on mobile, or something else? Because if the answer is ‘something else’, then this is a huge breaking change that would never be accepted by Wikimedia communities. The notion that certain features need to be hidden from people is not something that should be decided by WMF developers (which, let’s face it, don’t have enough hands-on experience here to know what they’re doing is good) without community approval.

On individual points:

1. Recent changes access is not something that should be tied to rollback permission, especially on smaller wikis. In fact, the way you usually get rollback is by showing that you have the capacity to know what to revert before that, which is usually facilitated by having RC access. Here I am a bit of a maximalist where I don't think it should be hidden from anyone, logged in or logged out.
2. Can you clarify what’s the intent behind hiding user talk page and sandbox links from registered users? Even if they do not exist, I assume mobile website is advanced enough to show a notice about it to anyone who decides to go to those links?
3. Community portal is not that important on larger wikis, I guess. On smaller ones, it’s basically the only community forum (which, if the wiki is really small, gets abused by WMF spam letters).
4. Hiding watchlist unless someone has a user right sounds like an extremely bad idea. Watchlist is basically the primary way to track changes on pages people find interesting, if anything, when a logged-in user doesn’t use it and is editing pages, you should have some sort of onboarding encouraging them to start using it.
5. I don’t particularly understand why the ‘simplified’ versions of the special pages need to be kept if the mobile version has ‘advanced’ versions that hopefully work well for everyone (if they don’t, let’s improve them further). That just makes the system worse to adapt to and more unpredictable. Practically the last thing you’d want from a good interface.

In general, hiding certain things from the website based on user experience sounds like a nightmare. What this would become in practice is that editors on the wiki would point certain users to some features of the interface, those users would not see those features because they don’t have enough edits, enough groups etc., and then that arcane system would have to be discovered by someone through (hopefully) documentation. It doesn’t make the interface simpler, it makes it more convoluted.

Would be nice to finally address T54165: Links to talk pages in mobile view for all anonymous users while you’re at it.

You should consider enabling AMC for all logged-in users instead of proposing to limit the availability of crucial features on both mobile and desktop.

Much of the proposal is very enwiki-centric, most (smaller) wikis don’t have user groups like rollback or new page reviewer.