The Current Branch 2002 release introduced a feature to install SSUs first but only when triggered by the deadline.
From the docs:
"SSUs are installed first only for non-user initiated installs. For instance, if a user initiates an installation for multiple updates from Software Center, the SSU might not be installed first."

A lot of work has been put into encouraging user-participation in the patching process. I want the user to decide when they're ready to install the updates and avoid situations where the deadlines impact their work. In those scenarios the behavior introduced in 2002 therefore not helpful.

I realize that if a user manually triggers the installs one-by-one that there's not much you can do about it. However, in pretty much every other scenario I would like to see the SSU install first.

For example:
User schedules the install from the update notification dialog.
User clicks 'Install All'.
User select multiple updates, including an SSU.

Business Case (I know how you PMs love these):
The current CB 1902 implementation is going to make this conversation part of our helpdesk script:
“What screen is the app on?”
“Can you move that window to the monitor where X is showing?”

“No, not that one.”
“Nope, still don’t’ see it”
“Ok let me reconnect in full screen, please accept the prompt again.”
“No no no, don’t hang up the phone, that’s not how this works.”
“Ok, you should see a prompt to allow me to connect.”
“Nope it’s there, trust me.”
“Got it, thanks. Ok, let me move that over here.”
“Ok, I’m going to reconnect again so I can see what’s going on.”
Click
“You just hung up, didn’t you?”

This is going to waste time on support calls and leave both sides dissatisfied with the entire experience. In turn, customers will continue implementing other third party remote control tools. Remove Viewer was absolutely a selling point for ConfigMgr and was one of the features that lured us away from our previous solution.

Solution:
1) The ability to select any single screen connected to the remote device in addition to the current all screen view.
2) The ability to change monitor selection without having to reconnect the remove viewer.

Notes:
I could probably live with automatic reconnection provided that the admin stays in the Remote Viewer app at all times and doesn’t need to retype anything (device name/credentials) nor the end user re-accept the prompt if one is configured.
In my dreams the ability to pick a single screen is built into the full screen mode. In full screen mode the admin clicks a button that overlays each monitor with a number and an outline. If this sounds like display setting’s ‘Identify Monitors’ that’s because that’s exactly what I’m thinking of. However, don’t stop there. In that identification mode make the monitors selectable such that when I click on one it immediately becomes the single monitor I’m connected to.

We have a lot of different kinds of Dell client computers and some of the model names are very alike.

We also have a network which doesn’t allow us to use peer-to-peer techniques to lower bandwidth usage so we need to create rings and make a couple of computers at the time pre-download osupgrade packages and drivers before deploying an IPU to the mass.

Two of the models we have are "Latitude 7390" and "Latitude 7390 2-in-1".
(This is not the only combo of models that suffers from this behavior)
We've created one driver package for each of them.
But the "Latitude 7390 2-in-1" will always download them both due to what is stated here:
https://docs.microsoft.com/en-us/mem/configmgr/osd/deploy-use/configure-precache-content

"The actual query uses a LIKE statement with wildcards: select * from win32_computersystemproduct where name like "%yourstring%". For example, if you specify Surface as the model, the query matches all models that include that string."

"Latitude 7390 2-in-1" LIKE "%Latitude 7390%" will always be evaluated as true so a "Latitude 7390 2-in-1" will not only download the correct driver package, but the package for the "Latitude 7390" as well.

This is the direct opposite of what we're trying to accomplish, saving bandwidth.

Suggestion:
Add an "Exact match of model name"-kind of checkbox to driver packages and make the query model="yourstring" if it's checked.
Or even better, let us write the query, just as with conditions of a TS step.

When I started working with SCCM years ago I was told that you're not really an SCCM admin until you accidently deployed MS Office to the whole company. Through my years of working with SCCM I've seen many people update a collection not knowing that there was a mandatory deployment attached which resulted in the deployment getting sent to systems that were not intended.
I would like to see a check/notification box added when a query based collection is updated that reminds you of the required deployments attached. This message will only show if an unexpired required advertisement is still set. This would ensure that admins understand the potential impact of their collection change.

Companies are looking for alternatives to the large public CA authorities like Verisign and DigiCert, one such alternative is Let's Encypt. They offer free public-signed certificates, the only problem is the certificates need to be renewed every 90 days. The renewal can be automated using Certbot.

However there does not appear to be any functionality in the current ConfigMgr release to allow for automated certificate replacement/renewal. This seems to be a gap in the PowerShell functionality.

Sure its only a few minutes every 90 days to log into the console open up the CMG instance and update the certificate, and this is not an issue if you only have 1 CMG but if you have multiple CMGs or CDPs that need updated certificates this could become very time consuming.

Automation is the key and if we had an ability update these certificates from a PowerShell cmdlet it would help with the whole automation process.

TL;DR: Make Phased Deployments for Applications the same as Phased Deployments for Task Sequences where you can create up to 10 phases and manually initiate the second phase of deployment.

Explanation:
Currently in 1806 although you can create a phased deployment for an Application, you're limited in two key areas:

1) You cannot manually create phases for an application
2) You cannot manually begin the second phase of deployment for an application
3) You are limited to 2 phases for an application

In our environment we follow a controlled graceful deployment process where an Application Model application is deployed office-by-office to prevent flood of support calls should an unexpected situation arise. Since we have multiple offices across the globe, a single application may have as many as 13 deployments, although it's typically around 6.

Phased Deployments is the solution here but it's usefulness in the context of Applications is limited. If it could match features available in Task Sequence deployments it would be of significant value.

Documentation:
https://docs.microsoft.com/en-us/sccm/apps/deploy-use/deploy-applications
https://docs.microsoft.com/en-us/sccm/osd/deploy-use/create-phased-deployment-for-task-sequence?toc=/sccm/apps/toc.json&bc=/sccm/apps/breadcrumb/toc.json
https://docs.microsoft.com/en-us/sccm/osd/deploy-use/create-phased-deployment-for-task-sequence