Roles and permissions

There is a trade-off at work here. At one extreme you have a single capability, moodle/site:config which controls everything. That is the simplest to set up, and keep the define roles screen shorter. At the other extreme, you create a separate capability for each admin setting, and the roles screen becomes even more ridiculously long than it already is.

In practice, the correct solution will be somewhere between those two extremes. Where a significant number of people have a good reason for being able to control something separately, we normally do create a separate capabiltiy. But as you say, we started from a situation (in Moodle 1.6) where there was only one admin role that could do everything. And we are gradually adding capabilties, where a big enough need is identified.

The structure of the admin menu is stored in the files in admin/settings. users.php and courses/php are good typical examples. You will see that already there is the facility to restrict particular settings pages, or individual settings, based on a particular capability.

And you will find that the admin block magically only shows users those links that they are allowed to access.

So if you create you sub-admin role with only the capabilties you want people to have, and not moodle/site:doanything, then you should be able to achieve some of the things you want.

Now the problem is, for some of the things you want to give subadmins the right to do, you will need to give them moodle/site:config, but that will let them change things you don't want to allow. For that, you will have to hack the settings files (and for external pages, the pages pointed to). If you think your changes are sensible, and something that other people might want, you should then create an issue or issues in the tracker with your proposed improvement, and see if you can get enough other people to vote for it that it gets included in core.