Once the cache has been filled all subsequent application deployments fail until the cache self-cleans. In CAS.log you see that the client is refusing to download the content because the cache, not the actual disk, is full.

This strikes me as a non-optimal design choice if the goal is to successfully install applications. If I want to install an application I do not want it to fail because of an artificial limit that until very recently was set at the time of client install. Most of the time the cache clears in 24 hours and there's no problem but there are two specific and prevalent cases where it is.

Task Sequences: During OSD we want every app and every update applied before the user gets the machine and we want it done quickly. It's very easy to go over a limit that day-to-day is ideal. This has forced SCCM admins to either abandon the application model during TS (a common MVP suggestion) or write custom scripts to temporarily increase the cache. Neither of these are ideal.

Large Applications: There are some applications (ex. CAD) that are just incredibly large (20+ GB) and all their own will exceed what an organization desires to reserve for cache size. Again, admins are either abandoning the app model entirely for these or running temporary cache modification scripts. This simply shouldn't be necessary for a system designed to deploy applicatons.

So, what to do? One option would to implement a rolling (first in, first out) cache where if cache space is needed the oldest non-persistent content for a compliant application is removed to make space. If the new app's content is larger than the cache itself then simply don't cache it. The only hard limit should be on the amount of free disk space to reserve before the SCCM client refuses to download content of any type.

TL;DR: Stop breaking application deployment just because the cache is full. No one wants to troubleshoot app failures.

Creating SCCM Collection Queries is an art, and like most art, some of us are more suited to stick-figures while others produce beautiful creations worthy of a place in the Louvre, featuring graceful sub-queries, artful tabbing and good code practices.

When creating a collection, it would be helpful to have an optional 'Community Collection Catalogue' to choose from, which could have a user-voice style 'Most useful' collections list.

Users could create collections here, possibly even having a community 'wish-list' area for those without skills to request from those who would like to share.

Contributions in the community catalog could be counted for MVP or other recognition, possibly displaying badges. Gamification elements could be added, including Facebook or Twitter links to individual contributions.

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.

It would be nice to have the ability to conditionally pre-cache all packages in Upgrade TS and not only OS Upgrade step.

To describe it in more details, in current design we are able to pre-cache only OS Upgrade step to computers based on conditions. This is not enough for companies with 20+ languages as best approach is to create en-us core image and then apply MUI on top of that. Doing this will cause system to report as e.g. de-de so we would need to download and distribute to 150+ DPs all supported Upgrade packages instead of distributing only en-us Upgrade package and them distribute much smaller MUIs.

As SCCM is currently supporting conditional pre-download in OS upgrade step so the function is already there, extending it to whole Upgrade TS will be a great benefit as we can then also put there e.g. Driver packs => so client will download only applicable driver pack, en-us Upgrade and appropriate MUI from one larger Upgrade TS. Right now we have to have 50 different Upgrade TSs to be able to support all languages in our company.