In SCCM, there should be a way to stop or discontinue a software deployment should there be an emergency or issue and then resume the deployment when desired. For example, if software has been deployed to the environment and in an event of an emergency or major issue, SCCM should allow the administrator to stop or pause the software deployment in real time, resolve the issue then restart the software deployment again. Ideally, this would accomplish in one push of a button. Unlike now, the administrator goes and deletes the deployment and recreates the deployment again leaving the inability to report on what has been deployed.

Please make it possible to change the target computer when using state migration points as a means of transferring user data to one pc to another.
The scenario would allow the backup (scanstate) of the old pc data, utilizing all positive aspects of SMP (centralized, encrypted, storage based on boundaries). IT could then later set target computer, which may not be known at the time the data gets saved.
Ideally this should be possible in the admin console by “editing” the state item to map to a new computer, just after it has already been created. “Late mapping” so to say.

When users receive notification of upcoming required deployment, allow users a 4th option to defer install date to be sometime during grace period. This could be a date input field with a drop down calendar. Available dates should be between deadline and end of grace period.

The notification would have 4 options:
1. Install Right Now
2. Install After Business Hours
3. Defer Install on a specific date during grace period <-- This being new
4. Snooze notification

Additionally, when notification appears for deferred install date...user can choose a new deferred install date as long as the user is within the grace period.

Also, please provide a new state for the deployment like "Deferred". This will tell us that the user deferred the install date beyond the deadline but sometime before the end of the grace period.

With SCCM 2012 we got the single instance store on the back end which reduces the need for storage significantly on the server side but on the client side there's no optimization whatsoever.
If you for example have 2 applications or deployment types which are using the same or almost the same content they are downloaded both separately. This has a negatively impact on the disk space you need to reserve for the client cache but also on the bandwidth used to download almost twice the same content. I believe this can be done better.
Many folks had to configure a client cache of 10GB or higher in SCCM 2012 which might not be a big deal on a desktop with a traditional hard disk but it comes a big deal when you think about devices like laptops having a smaller SSD, or tablets with only 32 or 64GB of storage and it also affect windows to go users and VDI machines.

There is SCCM CB 1806 (5.0.8692.1509) with the update "kb4462978" in the console installed.
When using automatic upgrade and package deployment to provide CM client version upgrades,
From the distribution point, although "client.msi" can be acquired, if "configmgr 1806-client-kb4462978-x64.msp" can not be acquired for some reason, a scenario occurs that results in "5.00.8698.1008" version did.
If the MSP file can not be obtained, CM client version upgrade is expected to fail, but the result is not "5.00.869. 1509" but the "5. 08. 692. 1008" version.
Success itself is a problem. The administrator misunderstands that the version upgrade of the CM client by the target version is successful.

As a workaround, for example, it can be avoided by including "configmgr 1806-client-kb4462978-x64.msp" in "client.msi".
If it is a version other than the purpose, we will ask for functional improvements that make it fail.

Today in the Modern workplace of Autopilot provisioning; Organizations decide to keep everything on Azure Active Directory (Device Identity and User identity) with co-management capabilities.

Currently Azure AD Group Discovery does support to discover only cloud based resources.. But to enable Advanced deployment targeting; it would be better to enable these discovery methods.

(i) Able to discover Hybrid Users as well not only for Cloud Users
(ii) Able to discover AAD Joined devices through Device Discovery especially Intune and Autopilot enrolled.

Through this; organizations will be able to create SCCM Deployments with Device and User Group Membership through Advanced customized targeting.

Here’s the problem. Systems exist in the Domain Computers group and other groups, so any recursive discovery of groups for the domain will put the partial system discovery back in the system.

https://docs.microsoft.com/en-us/sccm/core/servers/deploy/configure/configure-discovery-methods#bkmk_config-adsd
Starting in version 1806, select subcontainers (and/or OUs?) to exclude from this recursive search. This option helps to reduce the number of discovered objects. Select Add to choose the containers under the above path. In the Select New Container dialog box, select a child container to exclude. Select OK to close the Select New Container dialog box.
Tip
The list of Active Directory containers in the Active Directory System Discovery Properties window includes a column Has Exclusions. When you select containers to exclude, this value is Yes.

Good:
INFO: discovered object with ADsPath = 'LDAP://DC.EMSLAB.LOCAL/CN=AZUREADSSOACC,OU=Do Not Discover,DC=emslab,DC=local' SMSADSYSTEMDISCOVERYAGENT 10/10/2018 6:09:56 AM 20196 (0x4EE4)
WARN: Discovered object is in excluded AD container. Skip. SMSADSYSTEMDISCOVERYAGENT 10/10/2018 6:09:56 AM 20196 (0x4EE4)

Bad:
INFO: Processing discovered group object with ADsPath = 'LDAP://DC.EMSLAB.LOCAL/CN=Domain Computers,CN=Users,DC=emslab,DC=local' SMSADSECURITYGROUPDISCOVERYAGENT 10/10/2018 6:14:00 AM 6756 (0x1A64)
INFO: DDR was written for group 'EMSLAB\Domain Computers' - C:\Program Files\Microsoft Configuration Manager\inboxes\auth\ddm.box\userddrsonly\asgx21yd.DDR at 10/10/2018 6:13:57. SMSADSECURITYGROUPDISCOVERYAGENT 10/10/2018 6:14:00 AM 6756 (0x1A64)
INFO: DDR was written for system 'AZUREADSSOACC' - C:\Program Files\Microsoft Configuration Manager\inboxes\auth\ddm.box\adh4b27e.DDR at 10/10/2018 6:13:57. SMSADSECURITYGROUPDISCOVERY_AGENT 10/10/2018 6:14:00 AM 6756 (0x1A64)

Net result is nothing is cleaned up in SCCM and defeats the intention of the exclusion.