It’s a tough one! As I implied, the ability to clone things is something that comes up now and then, and we didn’t want to do that as this program appeals to a broader audience than just those that are aware of some more advance outlining techniques such as these. Since the most common request for this capability was to make lists of things scattered from around the binder, it made sense draw a much harder UI line between “binder” and “lists”, instead of trying to merge the concepts together. So that’s why it is the way it is, it doesn’t work for everything, but it does handle most of what people want for cloning.
We did in fact entertain the idea of “multiple binders”, and thus multiple structural treatments—but whew that gets real messy real fast even just purely at the conceptual level. What to do with 32 files that in structure A are nested beneath one group that has been trashed from structure B? Do we now have two items, one for A and one in the trash for B? Do the 32 files just get tacked on somewhere having been orphaned from the tree? And then what happens when you empty the trash for structure A, having forgot about the container in structure B that got trashed? Well, that’s just one problem. 
We gave it a good stab though as I recall, before concluding a simple list of files stored separately from the primary tree structure did 95% of what people want, with far less interface and potential for confusion, and with several months less coding and design time at that.
Maybe some day, we’ve learned much from iOS synchronisation, even solving some of those problems since syncing conflicted projects is by definition the resolution of multiple structures—but I wouldn’t keep my fingers crossed if I were you, certainly not for anything in the next few years.