Okay, I think a tip that will help you out is that collections are not actually binders. There can only ever be one binder in a project. Collections are portals for viewing select portions of the binder in useful ways as you see fit. You might have twenty articles that are scattered amongst various categories in the binder, but you wish to view them all together in one spot. You don’t want to actually move these items and collect them in one spot in the binder, because their original placement is important for their context (perhaps they are meant to compile together into a longer piece and need to be in that spot). This is where Collections step in. You can gather these disparate pieces from all over the binder and show them together as one list.
So when you create a bunch of empty Collections, as you have done, and then start adding items directly to them, Scrivener doesn’t immediately know where to put them. Collections are themselves an abstract sorting mechanism that exists by design completely divorced from the ordering in the binder—but since all newly created items must appear in the binder somewhere, that being the fundamental resources management tool in Scrivener, the software creates a “COLLECTION NAME (Unsorted)” folder in the binder for you, and starts adding these items to it as you create them. The idea being, once you’re done brainstorming or whatever in the collection, you would move back to the binder and sort these items out to where they should go in the master outline. Or you could just leave them there, nothing to prohibit against that.
So really, I think what you want here are folders in the binder, rather than collections.
The actual hierarchy goes like this: Projects are the master container class in Scrivener. They are individual packages on your computer, stores like normal files in your user folder. A general rule of thumb is that you create a project for each real world project you embark on, though there are many exceptions to that rule. As a journalist you might very well want to store many related articles in a single project—all being too short to have their own projects and be separated from one another’s research material. To take it to a larger example, serial novelists like to use a single project for multiple books so that they can use the same universe info for them all.
Theory aside: the project is the largest category of division in Scrivener. It is a hard wall where nothing inside of the project can “communicate” with things in other projects. You can’t share keywords between them, or link items between two projects. They are meant to be discrete. What you do inside of them is up to you.
Next “down” in the hierarchy is the Binder. This is the master list for each project. Every single resource in the project (with the exception of the contents of the project notepad) will be listed in the binder somewhere. It is impossible to have a file in the project that is not listed somewhere in the binder. You can have many folders within it, but each binder has one “draft” folder which is the primary focus of the project. That is where the production happens. Whatever you intend to produce with this project should be going into the draft. If a project has multiple productions (like a series of articles), then they would all go into the draft—probably each into their own top-level folder.
Everything outside of the draft is presumably in support of the draft. That might not always be the case, but that is the general rule of thumb and how the software is designed. There are no compile facilities (production tools) for stuff outside of the draft. They can be individually exported as files, but that’s it. The research folder is the exemplar of support material organisation. It cannot be deleted, to reduce confusion, but it doesn’t necessarily have to be the only sorting folder at the top level. You can have dozens of top-level folders—or you can just put everything into research to keep the top-level simple. That’s totally up to you.
So the binder is the master project list.
Below that level of organisation, I would say the container is the next; most common container is the folder. You have folders in the binder—and in Scrivener the folder is a tricky beast because it is an outliner, not a file manager. Files can be sorted into files just as easily into folders. So you will see the documentation refer to organisation as being “container” based. A container is a folder, a container is also a file with sub-documents.
Collections are strange because they are in every sense lateral to the binder. They do not represent an level of organisation above or beneath it, but rather beside it. Nothing you do in a collection will adjust the contents of the binder (save for creating new orphan files within a collection, as you’ve witnessed). No amount of moving items into or out of, or rearranging them inside the collection will impact the binder. Nothing you do in the binder will change the collection contents or order (short of deleting a resource). Adding an item to a collection does not move or copy it—it creates a link, or alias, to it. Thus you can have one item in twenty different collections.
They are a more advanced feature, in part due to this abstraction, but mastering them can bring your organisation and workflow to new levels. They are not necessary, however, for much of anything. They are a special purpose tool.
Outside of your own personal organisation, collections have two special purposes which elevate their importance a great deal. They can become surrogate “drafts”. When you compile, you can select a collection to compile instead of the draft folder or a container within it. Their second role in compilation is filtering, which is an even more advanced concept. Say you have some items in the draft you don’t want to compile—you can throw them into a “Do not compile” collection, and then set a filter in the compiler to strip any items found in that collection out of the list. Again, here we are getting into some of the really super-powerful aspects of Scrivener, and it is safe to just set this aside as academic information for now. Just now that collections can become a power tool to solve some tricky problems down the road if you need it.
So in summary: Projects → Binder → Containers (Folders) → Files. Then meta to all of that, Collections, which ignore all boundaries within the project and likewise impact nothing.