Jan, you are correct that we wanted to provide some good examples for packaging and make things look good. I too agree that it was a nice goal and I am glad that we spent the time to make it look pretty consistent. I spent a bunch of time on this (packaging, putting under source control) and Nik spent lots of time renaming things to be consistent and clear too.

One thing that really stuck out from the submissions is I don't recall a single container/skin installable using separate packages in the .dnn manifest file. I assume this is because there is no automated way to do it via the DNN User Interface or maybe people just didn't know it was an option. The reason we encourage separate packages (in a single file) is because they both register as extensions in the DNN Extension Manager and are installed from a single download. Doing this means someone could remove one package (the skin) while leaving the other package installed (the container). 

As for the skin object in the package. I understand what you mean here, however, I still believe strongly we did this the right way. In my opinion, the installer itself here is what needs updated (I have many reasons for this but don't want to discuss as it is off topic here). People want a single download that installs everything in order (the skin object must be installed before the skin). Basically, this along with the separate skin/container packages discussed above (because of registering them as separate extensions in DNN) are a few of the reasons we chose this route. 

More often than not, someone will install a skin and have no conflict. The only time this will occur is when 2 skin packages use the same skin object (or widgets but only 1 contest entry has a widget). That said, people who download all these skins and install them are certainly going to see this warning. The system here does not error out, it just provides a warning that is misleading (which is part of what I think needs to change in the installer itself). This is a usability issue and you will be hearing more about this and the skin packaging reasons later now that I have some time to blog about it. 

I do like single package for fresh DNN install, or people not so proficient in DNN.

However, I do agree with Jan too. Traditionally We had everything separate as that was the correct approach if we wanted to support the skin package long term. By that I am talking about skin packages we we have been supporting for 5 years through so many DNN Versions.

I think Now the landscape is even more complex compared with a few years ago when we only had Solpart. DNN Menu, Solpart, Third party menus (Snapsis, Telerik), Free Menus (DNN Gardens, HouseMenu) so many skin objects around.

For example we have produced 100s of skin packs using the Telerik Panelbar or Rad Menu that now seem to conflict with DNN own wrappers. Perhaps the solution is to provide both methods. It really does not add any extra time for a developer as they would have created the single package first followed by combining them.

1. Single Package for specific versions of DNN
2. Separate Packages for custom installs.

Salar