I have an ever-growing project. There are thousands of items. Checking off combinations is tedious. It would be cool if I could save different groups of compile items for different purposes.
This will not be so much of a problem once you upgrade to version 3 (in public beta at the moment). The checkbox you are using was never really meant to be used like you are describing, rather it is a better tool for cases where the thing in question will never compile ordinarily, like chapter notes or an old revision of a section.
In the future, look for compile filters, and how they can be used along with metadata (custom or otherwise), and collections, whether hand-selected or driven by search queries.
I know weāre not supposed to +1 requests, but I would really like to have this feature too. And rather than open up a new request, I figured it would be better to just lend support to this one. 
In that respect, I second the motion. Or I third.
Please do note, as was said in the response, this request is already addressed in the modern design of Scrivener, which is currently best expressed in the public beta for Windows users.
There is no need to +1 or add additional motions.
Perhaps I donāt understand the response above?? I am using the Beta 3 version. Am I missing a feature (which wouldnāt surprise me a bit ) Or has this not been implemented yet? Or something else?? I would really like to be able to create a set of compile settings and then save them in a list with a name so that I can open compile, find the entry in the list and hit compile. I go back and forth between various output formats-- but more to the point, I often compile fragments of the whole manuscript in the same output format style, and it would be really nice to be able to quickly select what I need without having to bumble around the compile settings-- which invariably ends up in me screwing them up for my main document.
Well! If youāre using the beta then you are fine. 
There are numerous ways in which to filter what gets compiled, or to set up custom lists, either permanently or in an ad hoc fashion using whatever you selected in project before pulling up compile.
All of this is found within the Contents compile options tab on the right side of the window. In Ā§23.4.1, Contents Tab, of the user manual PDF, youāll find an illustration with markings on it. (a) is the dropdown you use to select search results, collections and selections as your source list (you can also just pick out subfolders to compile individually, though thatās been around since version 1). This is the easiest approach, and closest to what you describe as having a list of compile jobs.
Secondly, the filter button marked (b) is a powerful tool, and probably your best bet for this kind of stuff in most cases. It has the same options available from the main compile group dropdown, but instead of building a new flat list (which can have formatting repercussions) it uses the list you provide as an include/exclude filter. Want to compile everything in your Draft but items marked with the āRedā label, without otherwise touching a single aspect of the hierarchy and order? Filters! Skip down to page 451 for the details on that tool (and pardon the Mac screenshots for the moment).
And yes, you can combine these two tools together as well, for example compiling only items from a search result collection that looks for things flagged āRough Draftā, that has filtered out all items labelled āSent to Editorāāan now youāve got a focussed proofing list.
[b]Hi AmberV,
Thank you for your reply!![/b]
(ADDITIONAL - I do understand that I can save settings-- sortaā¦ and I think thatās a cross between what the program can theoretically do and what I, myself, have learned/figured out in terms of how to do itā¦ I wish there was āOne Settings List to Rule them Allā for the reasons Iām about to illustrateā¦)
Iāll be honest, Iāve tried a number of times to wade through the compiler portion of the manual, and while I donāt doubt for a second the brilliance of the technology (nor the stupidity of the user 
), I often canāt make heads or tails of how to use it-- beyond picking the type (Print / PDF / Epub / etc.), the checkbox options (etc) in the tabs on the right-- but you completely lose me when it comes to figuring out how to design / assign sections in some way that coordinates to the folders and subdocuments in my manuscript. And I invariably get my Front Matter settings screwed up such that it takes me a lot more time and fiddling to try and get that straightened out again.
FROM HUMBLE BEGINNINGSā¦ (cue the violin music)
Itās not that (I think) I donāt understand the concepts, but what I see (experience) in the document area (scrivenings section? NOT the compiler dialogā¦) doesnāt always seem (feel) like it lines up with what I see in the compiler dialog.
Of course, you might say, āThatās on you-- you bought it, now put some effort into learning how to use itā ( ). And that could be a fair retort too, I wonāt argue the point! But hereās the thing, I have actually done that-- to a certain extent anyway.
We have a difference in objectives, you all and Iā¦ My main focus is on writing my book rather than fiddling with buttons and knobs in the compiler. But I have actually tried on a number of occasions to get it right. And sometimes I do learn some stuff that way. (Plus, I can always fall back on the āme being an idiotā claim, which as far as I can tell, isnāt that difficult for most people to believeā¦ )
So hereās where it gets frustrating for meā¦ letās say I get a set of settings that I like for say making my epub2 document. Then I decide I need to print a subset of the document, with some elements in the front matter omitted (just as an example)ā¦ so this requires me to make a number of specific changes throughout the various parts of the compiler.
Then when Iām done doing that, I want to go back to my original settings (that I had figured out previously, which had been working fine for me)-- and I discover that something isnāt right about my front matter stuff anymore-- something (Iāve probably done) has gotten it out of whack. So then I have to dink around for another half-hour to an hour figuring that outā¦ and when I finally do-- thereās no place I can save all my hard-won settings so that I can easily return to them later.
So what you are in effect doing, is TRAINING ME to NOT use the features youāve worked so hard to create, simply because my USER EXPERIENCE is (to me) frustrating and unwieldy. Because I donāt feel safe/secure that I can return to something familiar-- it doesnāt seem intuitive to me (probably my fault, Iām not knocking the software)-- but ultimately the bottom line is I walk away with the feeling that itās āFāin Magicā and the best thing for ME to do is not to mess with it !!! And I doubt thatā what you all really want-- or me either, for that matter.
So Iām giving you my honest feedback of the thing-- which I think at least a few other people feel and share too, or this thread wouldnāt have already existed.
SUMMARY:
1. I am willing to invest my time in learning, but only in bits and pieces as I have time or need a break from writing, or have some specific thing I need to do.
[Perhaps you all might consider producing a āCookbookā-style guide to go along with the regular manual to help people achieve specific things quickly. It would focus more on the doing (the application) rather than why you do it (the theory). (BTW - If that already exists, please let me know!) And, of course, for each item, you can always say, āTo learn more, go to section blah blah blah of the userās manual.ā]
2. It would be very helpful to have the ability to save my complete set of settings in a master list somewhere so that I could easily call them up when I need them. This would maximize the return on the time that I spend wading through, tuning and tweaking to achieve a specific purpose. To figure it out ONCE so that I can return to the original point of buying Scrivener-- to write. )
3. Having that type of facility would ultimately allow me to invest more (aggregate) time in experimenting, trying new things, working stuff out, and learning, since I could recall the set of settings where I understand how I arrived at them, and thus can more easily pick back up where I left off. And also because I would feel like I had the assurance that if I screwed it up royally, a single click would return me to a KNOWN, FAMILIAR set of settings. I do not have that confidence the way it works presently.
WRAPPING-UP:
I like Scrivener, but I give the Compiler the āDeep Voodoo, Vampire Crossā every time with my fingers because itās so daunting whenever I look at it, and frustrating and unintuitive (to me) to wade through it. And I have ZERO confidence that my ālearningā wonāt screw things up to the point that Iāll have to spend hours trying to figure out how to get it BACK to something that at least worked a little for me.
Does that make sense?
NOW can I vote for this feature???
No. 
Because (a) as you noted already we donāt do features by popular request and (b) now youāre talking about something way beyond the scope of what the original poster was talking about (I think?). Weāve gone from saving sets of Draft items to select between when compiling, to saving the entire compile setup into presets. I donāt even think most people would want to conflate the two, honestly. If I switch from proofing chapter 8 and 12, to printing the whole draft, I donāt want to lose dozens of settings that I now have to painstakingly recreate from memory because they are off in an other preset. I just want to compile chapters 1 ā 24.
So maybe thatās part of the confusion here. I am answering the original posterās request of providing a better way to switch between compiling chapterās 1 ā 12 and 13 ā 24, and thatās it (as far as the concept goes).
As to addressing what they want, maybe things are being overcomplicated by some of the aboveābut this specifically is as simple as this:
- In the binder, select all the files you want to compile and use Documents āø Add to Collection āø New Collection. Call it āCompile Jobā or whatever. Since it is a collection these items can come from anywhere, front matter, draft folder, research. They can be added all at once or assembled and carefully curated gradually over the course of years.
- Open Compile, click the filter button, and enable Apply filter. Set it to: āIncludeā āDocuments in Collectionā āCompile Jobā.
- Compile.
As you work, edit the Collection to change what compiles the next time, using the normal collection tools, and then compile again without changing a single setting in there.
To get back to defaults:
- Open the compiler, click the filter button and disable Apply filter.
- Compile.
Nothing in any of that should disturb your front/back matter settings. You donāt have to modify any compile settings other than that one single checkbox after initial setup. That described method works best for some ways of working, but for others, having a few collections to select between (one extra click) will be beneficial, and again the binder selection option will be best for those where āsetsā really only means whatever they want to compile at any given moment.
If anything is not working as I described above, then those are potential beta bugs worth posting to the forum.
Now on that matter specifically, I do believe there are still one or two outstanding bugs with how front matter is handled in the beta.
By and large I would say most people are satisfied with how the compiler compartmentalises versus shares settings in the completed design. I donāt think weāve had anyone ask for SuperMetaPresets before, in fact.
It is segregated where it needs to be, and shares settings where it should. If you elect to strip all colours out of the document (maybe you use revisions) then that isnāt something you want to have to go in and remember to set every time you switch to a new file type. The main exception is the compile Format, which is bound to the file type, and that seems to please most people. If you switch to PDF you get your āManuscript (Courier)ā or whatever, and āModernā for HTML. Front and back matter should stick across all outputs unless you choose otherwise.