I've always understood that one of the main factors one should consider when factoring product functionality into VSPackages is the memory footprint. For instance, if a user had the ability to use one portion of your product without all of the others, then it may be a good idea to ship those editor, projects, etc in different packages. I've tended to have separate VSPackges for different project types, but many of these project types share lots of common code (references to shared assemblies), so the memory difference between having one project type loaded versus all project types loaded is less than one might think.
Also, I've found that there is certainly a development and maintenance cost associated with carving things up into multiple packages. For instance, my project types have dozens of commands, many of which are actually the same between project types, but which must be defined and maintained separately in each VSPackage. Cross-package communication requires, of course, the complexity of implementing and registering services.
So, for a new project, I'm considering if I would be better off consolidating multiple project types into a single package and generally trying to go with "fatter" packages -- particularly when there is lots of shared code.
I'd be interested in others thoughts and what the MS prescriptive guidance might be on "skinny" packages versus "fatter", multi-project type packages.
Thanks in advance.