No, this is not what I'm talking about:
Folder A <- package 1
item 1
item 2
Folder B
item 11
item 112
item 113 <- package1
item 22
Folder C <- package1
item 4
item 45
item 5
In this scenario the package item 113 would wrongly become a root level item and lose its proper place which is relevant if folder B happens to be a chain or filter.
The second issue I see is that you get into trouble if you move package elements via drag and drop to other packages or move elements from a package to your general system. If you uninstall the package those items would be uninstalled as well because they belong to the package that is being uninstalled. This is obviously not what you'd expect and correcting this information manually is error prone and a lot of work imho. This is why I currently favour a simple top down approach. In above example Folder A + C would be part of "package 1" and item 113 would be ignored. If item 113 is to be included in package one it would need to be moved either to Folder A or C or a new folder D would have to be created and included into package 1.
The last option would be to include Folder B into the package if item 113 is supposed to be a
sub package. This leads to the only problem that has to be solved at the moment in my opinion, namely how to define sub packages properly. If item 113 is a sub package e.g. a special trigger for a special class specific package (Vadi has this sort of upgrade packages in his Lusternia system) them we'd need to introduce dependencies into the package system. In this case including item 113 into *sub package* 1 requires the existence of Folder B, a child item 11 which, in turn, has a child 112. If this is the case then sub package 1 can be installed. Otherwise you'd get an error that the package cannot be installed due to missing dependencies.
The question is how do we define dependencies in a meaninful and practical way.