The current implementation has also other disadvantages that's why I have asked if there is something about CB design I don't understand.
It also has some advantages, though. Imagine you want to create a simple "Hello World" console application. C::B offers 3 ways how to do it: Create a "one-file project" - thus, not truly a project but just a single file. You don't need anything else if you just want to try something. Then imagine you tried and want to have another target, let's say a debug-target. So you create a project which includes the single file and has 2 targets (e.g. default and debug). Again: You don't need anything else to solve the problem. Now you want to include a lib. Now you have 2 choices: You can add the lib as another target (targets are not limited to the very same source files) or you create another project. Both makes sense depending on your point of view. Once you start a "real" workspace (solution) you should create a workspace then that encapsulates sub-projecs.
I think the main advantage is simply that you create a minimal-set of project files depending on your problem. For a simple "Hello World" application why would someone require a project and a workspace (solution)?
I the end (IMHO) you have more flexibility. Furthermore C::B does not try to copy VS. So this approach (for me) was just something to get used to. But ones I did I found out the advantages of this concept, too. I'm just a user of C::B as you are but I wouldn't say that this concept has only disadvantages.
With regards, Morten.
Edit: In the end maybe a "Save completely all" ;-) menu function would do what you are requesting. Depending on what's open it would save a single file, one or more projects or the whole workspace including projects and files.