well also if it all happened in at once and to include a re-design as well i doubt we would want to release it under the guise of a minor release which would be from your perspective a non-issue in that case.

I am not saying that it would be a non issue I am just suggesting that it would make more work all round for both extension developers and the Extension team - and why should it be a "minor" release? I would suggest that the ACP redesign is a major release in its own right.

The point that I am trying to get over is that at a rough guess about 80+% of extensions will be affected by an ACP style change unless, at least initially, there is backward compatibility. Also if the structure of the ACP is changed then there will be quite a few extensions affected - so I would suggest that, again initially, that the module structure is not changed even though some aspects of it may not be used/needed.

Don't get me wrong here I fully agree that the ACP can at times be difficult to navigate (I sometimes spend ages trying to find little used options!) and that it is long overdue not only a style "makeover" but a general reorganisation - I am just trying to draw attention to the fact that extensions will be affected by this and that some consideration is given to the overall process of updating the ACP.

DavidRemember: You only know what you know -
and you do not know what you do not know!

Good catch and bad example.
I would never look for it on the same page. Here is (hopefully) better example:
In “User registration settings” → “Account activation” is written:

This determines whether users have immediate access to the board or if confirmation is required. You can also completely disable new registrations. “Board-wide email” must be enabled in order to use user or admin activation.

The admin/user experience is based on the study of the provided Docs/KB, there are also PDF downloads.
Moreover on the experience of each one. I am more pro to remove redundant code/housekeep it, at the moment ,and wait for the ACP/UCP/MCP to be rewritten/decoupled. Yours looks more like a feature request for which the 3.2 serie is closed.

...removing settings for the sake of removing settings isn't the goal. But removing settings which are duplicated on multiple pages is a good start.

That doesn't mean there aren't some settings that could/should go away, because they were created in a 2002-2006 world where the whole Internet was different - shared hosts were less capable, user download bandwidth was lower, no mobile web, etc.

What's your idea of realizing this? In the past I analyzed other BBS software to see how they did it just to realize all they did was providing "tags" per module (which, of course, is much less than all the captions being presented per module). So I came up with something to use language files directly (amongst others), and in Re: Search in ACP I published a modification for 3.0.11 - up to today I tweaked and tuned it even more and it works quite well in finding modules (and their appropriate modes).

What's your idea of realizing this? In the past I analyzed other BBS software to see how they did it just to realize all they did was providing "tags" per module (which, of course, is much less than all the captions being presented per module). So I came up with something to use language files directly (amongst others), and in Re: Search in ACP I published a modification for 3.0.11 - up to today I tweaked and tuned it even more and it works quite well in finding modules (and their appropriate modes).

Basically that. If an admin wants to change the PM limit per user but doesn't know where to find that setting, they can just go to the ACP, type something like "PM limit" and get the specific option. Since the ACP will probably mostly static this won't even involve server load but could all be done on the client.