Currently running SCCM 2012R2

We have multiple 'Deployment Packages' for our MS software updates.  I've heard that this is a messy way of doing things, that I really only need one to house all of them and that I can then use the Software Update Groups in order to segregate out the patches I want to apply.  However I am not certain of the best method to do this.  I want to consolidate and simplify the both the folder structure & the Deployment Packages if I can.

Is there any documentation that someone could point me to that outlines how best to go about it?  OR Has someone here done this before and could give me some gui

Even though it will work, I wouldn't throw all the software updates together in one deployment packages. The main reason is that you will get one gigantic package that will be a pain to distribute to distribution points. I would still keep multiple deployment packages and depending on your deployment strategies I would either group them by year or by product, or by a combination of the two.

Makes sense from the distribution perspective, but what about the folder structure?  As it stands now I've got about 38 Deployment Packages and a separate folder (Package Source) for each. I'd like to consolidate the folders (sources) if possible.

Each package must have its own folder so there's no real consolidation possible. Aren't all of them already under a single parent folder called Updates (or something like that)?

locations are like so:

\\SCCMServer\Content_Source$\Software_Updates\Package

... so that the names of the subfolders of Software_Updates match the package name.

I don't understand why each package MUST have it's own folder though.  This would indicate that if I have different packages for different computer collections (with only a few differences) then I have multiple copies of the SAME updates which would be inefficient space-wise.

Couldn't I just have all of the updates exist in Software_Updates and then each package point to this folder as it's source, but the package only contains the Members (updates) needed for that deployment?

We had a Microsoft PFE on-site some time ago helping us with another issue and he noted that what we are currently doing was inefficient and unnecessary that some type of consolidation was possible.  I just don't remember exactly what he said we could do and we didn't spend any time on it because we were more interested in OSD at the time.

All Packages in ConfigMgr must have their own folder, how else would ConfigMgr know which content belongs to which package? This is simply how it is and at the end of the day, the why doesn't really matter much.

Also, Packages have nothing to do with collections so your question doesn't make sense.

No to your third paragraph for the reason given. Each package must have its own unique folder.

There are a lot of opinions on software updates out there and multiple valid paths. There are some facts also (like each package requires its own folder). Efficiency is up to you to determine though.

I was able to get in touch with the Microsoft PFE that I had spoken to before, here is the answer I was provided:

"No matter how many packages that you create, Configuration Manager will not allow you to actually import duplicate updates. Although to answer your question more directly, there is no real requirement to use multiple packages, even if you are using multiple update groups to deploy updates. The package is merely a repository for the updates. If you do a deployment that references updates from [all of your] packages, it will find them wherever they reside and pull them down. This is different from normal software distribution where the content is contained to the one package (or application). So, you can simply create a package and for each update group you can just select the same package to store those updates. Keep in mind that a single update group should be at 500 or less updates for performance reasons."

So from this I can extrapolate that I can have 1 package for Microsoft updates and 1 folder to contain the source files, I will just need to create Software Update Groups of 500 or less for deployments.  That said I can further divide them to make distribution easier, perhaps by year, but each package need not have an individual folder just for it.  If they were for 3rd party updates maybe, but not for Microsoft patches, 2 packages can pull from a single, or multiple sources.

"Configuration Manager will not allow you to actually import duplicate updates."

That statement means nothing because you don't actually import updates into ConfigMgr unless you are using SCUP or one of the third-party tools that does the same thing that SCUP does.

Correct that there's no by design reason to use more than on package however there are practical ones: specifically when a package gets corrupted, particularly if it's a big package, it's very difficult to recover from without recreating the package and of course will have wider impact than a smaller package getting corrupted or failing to be distributed to a DP. I've seen this happen often for whatever reason (even with DPs in the same data center) and the best path is always to use many smaller packages to limit the scope of issues when they happen and reduce recovery time. 

As for the 500 updates per group, that is the 2007 number, in 2012 they are limited to 1,000.

And finally, each package *must* have it's own folder. That is once again by definition of what a package is. Mixing package source together is technically possible but not the by design path and will cause issues. I'm not sure how you keep coming to the conclusion that it is acceptable or why you'd want to do it in the first place anyway. That doesn't mean each needs to own share if that's what you're thinking, it's just means each needs its own folder -- two different things.