Idea for an enhancement: ability for a registered user to save favorite packages to lists, either for personal use or to curate collections of related packages for others. This would serve both as a bookmarks list when browsing the site, but would also be used for automatically batch-installing packages.
An advantage of adding first-class list support is to prevent the package namespace from becoming cluttered with personal lists, e.g. http://chocolatey.org/packages/alanstevens.utils (@alanstevens, if you read this, I think your collection is great - I just want a way to keep it separate from direct packages). This also has the benefit of allowing people to contribute to the community even if they are not package maintainers - curating useful lists of utilities, tools, or libraries adds value to the community.
This makes the most sense, perhaps, in the context of Chocolatey NuGet, but I could also see it being useful for development packages as well.
I'd like to see some discussion around this idea to see if and how it makes sense to implement it. I'm not familiar with the NuGet or NuGetGallery internals, but I am as web and .Net developer and I would love to help.
On the NuGetGallery side, it would require some UI work to allow users to add packages to lists, browse lists from a user profile page, and the underlying database work to back that up. To make the lists installable, I'm not sure if it would make sense as a meta package, with the list packages included as dependencies, or in a format similar to the packages.config file that NuGet already uses for package restore. By convention, lists could be made available by username.listname, and NuGet (or Chocolatey) could take advantage of the existing -Source switch to indicate which instance of NuGetGallery the username is scoped to.
If it doesn't make it into NuGetGallery itself, it's similar to chocolatey/chocolatey.org#1 so it's likely to get into Chocolatey.org
Batch installing from a custom feed would be a client feature and should be on nuget.codeplex.com. As for building custom lists of packages, this is definitely something we are planning. We have #440 to cover some basic Favoriting functionality, but it sounds like you'd want multiple package lists you could manage separately. You could also create a "meta-package" (a package with only dependencies on other packages) to simulate this.
This is a bit to broad right now, and we are planning on some major enhancements focused on building custom feeds, so I'm going to close this specific issue out.