A project might be intended to output different piece of documents where they share common pieces of texts. Using internal aliases one can share folders or texts between different some other folders where each of these other folder is supposed to be compilde to some specific document.
If I read correctly what you are writing, the Collections feature may already give you the functionality you’re looking for.
Yes, strictly speaking Collections are the answer to the requests for aliases or outline node cloning. Functionally, you may find this has some limitations for compiling—you can compile a Collection, but it’s not really meant for general production use, it’s more of a one-off tool—say if you want to compile all of the scenes in your novel that mention a red car.
There are tactics for storing multiple interleaved books within one Draft folder already. I have posted some how-tos in these threads:
And as noted in those threads, but the Scrivener and Scapple user manual projects available on our support page are working examples of cases where two different copies of a book are generated from one single Draft folder, with both the capacity to filter out entire sections, as well as phrases within sections. These are binary books, you’d need to employ further tricks if you have three or more editions coming out of one Draft, but I share some tips for that as well.
Thanks AmberV,
I used to use the Dynamic model (search based collections) and did not know about the possibility of restructuring the texts in collections. The latter one solves lots of problems, Just note that then I guess we could not have both the static and dynamic mechanisms at the same time.
In my case I have a book that consists of some normal chapters and some articles. Articles can be compiled independently. But the compilation as a part of a book chapter and as an independent article is different (authors list, keywords, abstract, …). At the moment I use the dynamic model to differentiate between book publishing and article publishing, masking some parts in each compilation. But this method does not allow me to use the same text in different structures. The text should be always a part of a master structure. Being able to do custom structuring in the normal collections solve this problem but then we cannot have the dynamic “search based collection”.
At the same time I feel the the alias folder/text logic is somehow simpler (well, not sure).
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.