Exposing Configuration Manager functionality through RESTful web API's would open up a whole new world for interacting with ConfigMgr.
E.g. a web Admin console and easier integration with Service Management Automation (SMA).
It should also be easier for 3rd party vendors to create new web based solutions for say an self-service portal or a Windows App for tracking an OS or application deployment on a mobile device or phone.
Personally I would really like any easier way to interact with ConfigMgr. when running in Windows PE (OS Deployment) or a web portal for non-admins to provision new or existing machine for OS deployment.

The original UV item for the content cleanup tool was closed when 1702 was released. However, that item has several suggestions for improvement that were not implemented:

Handle in-process or failed content. This can quickly become a catch-22 where content is failing because a lack of disk space. In process I understand, but if content failed then an option to force it anyways and remove any content not tied to a valid package.

Support cleanup of the site server's content library.

Minimize the rights needed to run the tool. Currently, the tool requires 'Full Administrator' which seems overkill. Why would it need to create apps/packages/drivers/reports and things like that? I'm hesitant to automate a process that needs to run with permissions that give full access to a tool with root access to every device in my organization.

Most importantly, please add this to the scheduled validation of DP content with the ability to track success.

Lastly, can we just solve whatever the underlying issue that orphans content? This has been a known issue since the 2012 release.

Today, when you install the CM Console, the PowerShell module will be placed under the %CMInstallDirectory%\AdminConsole\Bin\ConfigurationManager.psd1

This makes sense given where the user is choosing to install the console, and that's fine. But placing it here off the beaten path means that it is not importable using PowerShell's module autodiscovery features. For instance, if a module is found in any of the standard user or system paths (or registered under the $ENV:PsModulePath) the user can easily import the module without having to specify the full path, a big user quality of life win. This is the way that SQL Server handles their modules, and they are the golden child, beloved by all PowerShell nerdoes like me.

So, my suggestion is to continue placing it where it is today, and also register the path using the standard mechanism, excerpted below.

https://msdn.microsoft.com/en-us/library/dd878350(v=vs.85).aspx

We need a way to use PowerShell (script) to trigger a Reboot using the Software Center Dialogs. This way we can trigger a reboot at the end of an install which will leverage the CM built-in notifications.
https://docs.microsoft.com/en-us/configmgr/core/clients/deploy/device-restart-notifications

Currently, if you have a deployment that triggers a pending reboot, the machine with NOT actually reboot after the install, but instead waits for the deadline. Or if the Deployment had no deadline, the machine will never actually reboot.

We need a way to have CM trigger a reboot that we can call in a script, so at the end of an application install (or other use case), we can call the command to have the CM Reboot Countdown trigger (based on client settings) and reboot the machine.

More info in this Thread: https://twitter.com/adammeltzer/status/1249756471211909121

Today, you configure maintenance tasks under the administration workspace in the console. To see the results and details around those tasks, you have to go into the component status and parse through the SMSDATABASENOTIFICATION_MONITOR to see when tasks started, stopped, how many records were cleaned, or whether the task failed, or, you can run a query directly against the database that shows when the tasks last started/stopped....but even then the task names in the DB don't necessarily match the names in the console. I propose that there is an area in Monitoring workspace that shows the status for each task, for each site:
enabled/disabled
scheduled start window
last start/end
last result
result details (ie removed 1234 obsolete records).

It would be nice to have the Properties available to pass to an External Script the same way the Insertion Strings can be.
What I was specifically trying to accomplish in this case is Adding a Computer to a Collection during a OSD Task Sequence for the Purposes of Software Updates. I created a Status Message Filter Rule that looked for a Client State Message ID 11140 (The task sequence execution engine started execution of a task sequence.) for a Specific Package / Task Sequence. This all worked as expected and launched the external command when the TS Launched (and after subsequent reboots). The problem is that I can't rely on %msgsys to be the Name on the Record if I wanted to automate adding the Record to a Collection. During OSD of an Unknown Computer %msgsys will equal “MININT-xxxxxxx” and the Resource Record Name will equal “Unknown”. If I had access to “Client SMS Unique ID : GUID:” which is in the Properties I could Search SCCM for the correct record and retrieve any information I require to perform any activity.