I think it is safe to say that for most things, the Checkbox field is more useful as a writing and organisation tool, rather than something you would compile with (notable exception being the compile filter feature, where the Boolean can be used to determine whether something prints). But that’s not universally true, especially if you don’t mind employing a little post-processing. The way they should be working is that if the item is checked then the custom field will output “Yes” and otherwise “No”.
So if that output is placed in such a way that you can later post-process it to something more useful, it can become a functional tool in the compile phase. The attached project is a simple example of how this could be done. The “Done” checkbox is used to generate GitHub style task lists in Markdown format. The title prefix handles the initial inclusion of the custom metadata field, and the Processing pane uses a sed one-liner to turn “Yes” into “X” and “No” into a space. I left the processing pane disabled so you can see the intermediate result. Simply enable post-processing to view the correct GitHub result.
Don’t quite follow why you’d need that. The label is static, so you don’t need anything special there. If you want to print something along with its label:
Publication Date: <$custom:Publication Date>
Conditionals are something you’d have to handle yourself somehow—the premise behind the checkbox example should be enough to get you going there. At some point you may want to switch to using a full scripting engine to handle your output rather than sed.
…and wiping out the line, should be safe enough—but it could be made safer by using an intermediary result that is converted to two different outputs, one empty and the other properly formatted.
But in short, the answer to the questions of whether Scrivener supports programmable outputs is yes. You will need to bring your scripting knowledge to the table though, it doesn’t attempt to provide a simplified version of what you can do with full programming languages.
The user manual is a good example of this in places. Not all of what Scrivener generates is meant to be printed, and there is a Ruby script that it executes to convert the raw output at multiple stages into the final .tex file that gets used to create the PDF. It handles conditional small caps for example, to print “PDF” nicely in the text, but not as “pdf” (lowercase) in the digital ToC and headings, where the UI/font used doesn’t support small caps.
I certainly wouldn’t approach things that way in this case. To my mind that is mixing output intent with data too closely. It would be a mess if you needed to print only the data for some other purpose.
I have made exceptions now and then, but only for cases where the custom field is intended to hold actual direct syntactical output and has no other conceivable purpose.
Well, I skip the here-or-there problem by composing 100% in Markdown; just makes more sense to me all around, than using word processing stuff. Depends on what you need of course, but I’d rather have that kind of flexibility and power everywhere.
But no there isn’t a flag specifically for that—the closest thing is simple Markdown in titles and synopses, but that only refers to very simple Markdown. I don’t even think links are supported, and it’s mainly there for people that need partially italicised headings and such.