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.

1.) When running the SCCM Setup Wizard and choosing “Modify SQL Server configuration” there does not appear to be an adequate preflight check to ensure Config Manager is running with full administrative rights to A) operating systems, B) SQL instances and C) Config Manager itself. These permissions are (obviously) critical to a SQL configuration change. In enterprise environments, setup.exe should be reaching out to check rights to all the things it needs to modify (file system, registry, certificates, etc.) before it executes the changes. Partial modification of the configuration has catastrophic results.

2.) Execution of the SQL configuration change does not perform quite enough validation during modification to determine that each small change was successful, with errors listed in the setup.log. It is possible for setup.exe to complete with success according to the GUI, but ultimately fail to create certificates, registry changes, and propagate SQL broker updates.

3.) Documentation around how to effectively prepare and run the “Modify SQL Server configuration” could use improvements in the areas of A) minimum rights required to the OS CAS, PRI, SQL systems and CM, B) stopping site components C) detaching a database D) copying database files E) attaching and configuring the new database, F) running setup wizard with more detail around what setup.exe performs, and how long it takes... and last G) how to validate the changes were successful with SPDiagDRS and Replication Link Analyzer.

If you install Hyper-V on Windows 10, it will create a default adapter and randomly create an IP address, usually in the 172.x.x.x subnet. If by chance, you have a boundary that this random IP address falls into, the SCCM client will think it is part of this boundary, in addition to the boundary associated with it's physical NIC. The client considers both boundaries to be a Current boundary group and will therefore potentially download content from DP's associated within either boundary. In most situations, this additional DP will likely be across a WAN link which of course can cause issues.

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