DSC is a wonderful framework for handling baseline configurations across Windows and Linux machines, but it's completely unsupported in SCCM directly. While a Pull server is certainly more simplistic than an SCCM hierarchy, it would still be very beneficial to have some integration in a couple of areas:

Management Points can easily be configured to host mof configurations for clients, and a new client policy class for allowing the SCCM agent to configure the pull server settings on a host would be great. Alternatively a new role could be made ... not sure that would feel as elegant.

The baseline section could contain DSC configuration files or items for a more open/standard baseline control. THe current baseline scripts feel so dry it would be great to see it replaced with a standard DSC formatting.

The certificates store under administration can hold public keys for password encryption for MOF files when generated.

Distribution Points could house modules for said Pull server calls. Want to get clever? Blend in some chocolatey goodness and allow us to create ADRs for pulling the latest versions down on an interval.

Reports! Yes, the reporting module in DSC is dry ... and how great would it be to have some canned DSC reports for easy at a glance compliance settings.

Needs for confiuration are changing ... some great work is being done to make declarative configurations happen ... but SCCM still uses simple and clunky scripts for baselines. Lets standardize on power-shell already.

With CM Current Branch implementations, customers will have more questions than ever about whether their clients are being upgraded to the proper version. There are ways to get at this data in the CM console, but sometimes there are gaps (hotfixes come to mind) and it would be great to have an authoritative resource to point customers to. This site (https://blogs.technet.microsoft.com/configmgrdogs/2014/02/07/configmgr-2012-version-numbers/) is great but it seems to be maintained by a field engineer. I think it would be more practical to make this data available on Technet or docs.microsoft.com. Also if it could have site version, build, and client version (with/without hotfixes) it would be a big help.

Today it's only possible to orchestrate software updating based on a membership in collections.
This is however rarely enough for more complex setups where you might have back-, middle-, and front tiers in your setup.

Therefore I recommend adding a dependency system between computer objects, so that you can orchestrate at least the following:
1) Which tier of servers are patched first, second and third etc.
2) Reboot order between the different tiers which includes an accept of one tier being fully patched and rebooted before the next tier is begun updating.
3) Ability to choose between warning or rollback if a single server fails updating - however this should be possible to decide based on each tier. (you often care more that a database server is identical than a webfrontend).

The guid https://technet.microsoft.com/en-us/library/mt651651.aspx is incorrect or missing some steps.

1. It mentions Endpoints a few times, while it has meen listener. Listener is not the same as endoint . AONAG must have a listener and the listerner name must the provided as sql server name
2. The port of listener must match the port of SQL Servers
3. BEFORE adding the DB to AONAG (if the new server is different than current one), run the following:

USE master

ALTER DATABASE cm_XXX SET ENABLE_BROKER
ALTER DATABASE cm_XXX SET TRUSTWORTHY ON;

USE CM_XXX
EXEC sp_changedbowner 'sa'

4. After adding the DB to AONAG, failover to secondary server(s) and run the following:

USE master
ALTER DATABASE cm_ps1 SET TRUSTWORTHY ON;

USE CM_ps1
EXEC sp_changedbowner 'sa'

When I was moved my DB to AONAG, I also hvae many replication issues (I hvae moved a Primary Site DB). I needed to export and import CAS cert (on Primary and after failover to secondaries) and run exec sp_change_users_login 'update_one','ConfigMgrEndpointUserCAS','ConfigMgrEndpointLoginCAS on all AONAG member servers.
I'm not sure if the last two steps was an accident, but I believe, that DB movement from standalone SQL to AGAON was done correctly (with preinst /stopsite and running setup). Of couse above was done on 1602.