After reading everyone's arguments, I think Wheat Wizard's answer makes sense. This is a concurring opinion that looks at things from a Brachylog perspective.
Predicates and unification
Like in Prolog, a Brachylog predicate typically produces output by unifying a variable with some number of values, one after another. This type of output is considered to be a "generator" in our default I/O methods. For challenges that ask for a list, I and others have written Brachylog predicates that unify a variable with the first element, then the second element, and so on.
I don't think we should try to have our cake and eat it too. If unification creates a generator, and a generator is equivalent to a list, then a generator cannot also be equivalent to a single value whenever it's convenient to treat it that way. We should either use
findall when we want multiple values, or cut when we want a single value. Since there's already a consensus that unification means multiple values, let's stick with that.
To return a single value from a predicate by unification, we should make sure the predicate only returns one value and then stops. (If we think of unification as a generator, this is equivalent to returning a value in a singleton list.)
As I said in a comment, I don't think the same rules should apply if a submission is a full program rather than just a predicate. A full program that takes input, produces output, and halts should be judged on the actual output it produces. The fact that a Brachylog program is often a single predicate, and the fact that the predicate could have produced more results if it were called multiple times, is irrelevant in this case.
However, there are some caveats:
First, in Prolog, it's possible to run a program in such a way that it produces one output and then waits for the user to indicate whether they want more or not. This should not count as producing a single output; it is analogous to the generator case. That's why I included "and halts" in my full-program description above. If there is a flag that makes the program output the first result and halt, like Curry has, then that's fine.
Second, most Brachylog solutions are not full programs. I was a bit surprised to realize this, but reading through this comprehensive answer, it makes sense. TL;DR: If you pass an input to a Brachylog program and it prints
42 to stdout, that's a full program that outputs 42. If you pass an input and a variable name
X to a Brachylog program and it prints
X = 42 to stdout, that's not a full program that outputs 42; it's a predicate that returns 42.
The same reasoning applies to the Prolog answer that led to this meta discussion: its input is
9+A., and its output is
A = [2, 3, 4]. That's not a full program solution, it's a predicate solution. It could be made into a full program if it read input from stdin and wrote output to stdout, but of course that would cost more bytes.
Predicates and writing to stdout
Here's where it gets tricky: we allow functions to output to stdout. What should be done with a predicate that outputs to stdout? Maybe if it were called more than once, it would output more than one thing. Do we consider its output to be what it prints when it's called the first time, or what it prints when it's called until it fails? I'm not sure.
This is somewhat analogous to printing within a generator expression in a language like Python, except that in Python, you won't get any output if you return the generator untouched, whereas in Prolog and Brachylog, you'll get the first pass of output.
(Again, note that if we're talking full-program, the output should be whatever the program outputs, which is probably going to be the result of calling the predicate once.)