Module Improvements
Core
Special:ManageWiki/core could potentially be improved by maybe moving some of the primary settings, such as $wgFavicon, $wgAppleTouchIcon, $wgLogos (ManageWikiSettings has this split out as $wgLogo, $wgIcon, $wgWordmark, $wgWordmarkHeight, and $wgWordmarkWidth), $wgDefaultSkin, and $wgDefaultMobileSkin to Special:ManageWiki/core.
Extensions
One idea I have for this is to create a preference to be able to disable section tabs within Special:ManageWiki/extensions, except for "Other" and "Skins", which would revert to the old behavior of Special:ManageWiki/extensions. The reason this would be a good idea is that it would maybe allow easier discovery of extensions by being able to search using the browser word search functions. Additionally, the creation of the sections never went through community feedback, as it was before SRE started doing that. Whether this can even be done is yet to be seen, but it does seem like a good idea to attempt to do it. Furthermore, if the preference is not enabled, we should consider the redesign of the current sections for better discovery, as they currently for the most part use the sections in extension.json, which isn't always ideal, and it's hard to find some extensions.
Settings
Redesigning and reorganising the current sections of Special:ManageWiki/settings may be a good idea. We could also consider maybe pulling setting descriptions from the configuration description or descriptionmsg from extension.json/skin.json. Also, since Special:ManageWiki/settings, does support filtering by extensions or skins now at Special:ManageWiki/settings/<name>, we could maybe add a dropdown box or something above the form with options for every enabled extension and skin for easier filtering and visibility of each of their available settings, with the addition of MediaWiki core and all global extensions and skins as options as well.
Permissions
We could potentially improve Special:ManageWiki/permissions by maybe making it possible to add at least one configuration variable to the main part of Special:ManageWiki/permissions before entering into group permission modification. We could add the ability to create custom rights within the $wgAvailableRights configuration, which, of course, would need to be vetted to adhere to the disallowed rights, etc. But, doing this would potentially allow adding one of the most requested configuration variables to ManageWiki, $wgRestrictionLevels. If we did this, we could also consider moving $wgImplicitGroups to Special:ManageWiki/permissions instead of Special:ManageWiki/settings, where it is now. We could also consider adding $wgRevokePermissions as another tab in group permission modification to be able to configure that for each group. Another thing we could consider is supporting the new $wgGroupInheritsPermissions (added in MediaWiki 1.38.0) to allow certain groups to automatically inherit permissions from another group.
Namespaces
We could potentially improve Special:ManageWiki/namespaces by making it possible to add multiple values for $wgNamespaceProtection, as that config supports an array for multiple values as well. Some extensions even set multiple by default, but because of the fact we don't support them, ManageWiki only supports one, and therefore, only one is in the install step of ManageWikiExtensions. An example of this is StructuredNavigation for the "Navigation" namespace. The extension has two namespace protection permissions: structurednav-edit and structurednav-create. However, since ManageWiki only supports one, it only sets structurednav-edit in the extension install step. Another thing we may want to consider is allowing some of the ManageWikiNamespaces additional settings to be modified for the special namespace if it would work to do. Currently, the special namespace is completely disallowing modification, and under certain circumstances, setting additional settings for it may be necessary, or at least useful.
Global Improvements
User Experience
We could potentially improve the overall flow of the extension, by using heavy JavaScript, to make the user experience better, and allow us to continue modifying the main form after selection of a group or namespace in their respective modules, interactively with JavaScript, so virtually it would not need to reload.
Discovery
We should consider further improvement and discovery of ManageWiki as a whole to make it easier to use, provide better documentation, and make it more understandable and easy to use for less technical-oriented users. One idea could be a complete rewrite of the entire extension (or creation of a new module), which would essentially create a step-by-step wizard, either complete deprecation of the current modules or a whole new module, which you could use to find extensions or skins you want to enable, enable extensions or skins, continue to the next step, manage namespaces, continue to the management of permissions and settings for the extension or skin setup, with some sort for a wizard or something else for core stuff management.
New Additions
Supporting Hooks
We could potentially consider supporting some basic hooks in ManageWiki, potentially by creating a new "hook" type for Special:ManageWiki/settings, which would be able to modify hook output within ManageWiki. Of course, by doing this, we would need some sort of validation/sanitisation for user input within ManageWiki.
Better Validation of Configuration Variables
We should consider maybe something like a new ManageWikiValidation helper class or something to support better validation for numerous configs in both Special:ManageWiki/settings and Special:ManageWiki/namespaces. This would validate stuff like usage of https:// where required, to prevent user confusion, or CSP errors, which would sometimes be given if using http://. An example of this happening is T9032. If it is done incorrectly, then this would immediately give the user an option to correct their mistake and not save the setting otherwise.