The point is, the function shell-command does not use this variable because it only affects interactive use. So indeed, writing a command that invokes shell-command is an option, but it does make a use case for the existence of this variable.

My POV is splitting standard output and standard error (maybe on demand) is a basic usability requirement and should not require writing custom commands.

The problem is not with using setq by users, it is with getting non-developers to write and execute Lisp scripts to accomplish basic tasks, including scripts that just invoke setq. The latter obviously is not a problem when you are a scientist, but I imagine that the front end would be much cleaner if operable cleanly without scripting (again, this concept limited to basic tasks obviously).

26 sty 2024 15:41 Eli Zaretskii <eliz@gnu.org> napisał(a):

> Date: Fri, 26 Jan 2024 15:23:13 +0100
> From: Krzysztof Żelechowski <giecrilj@stegny.2a.pl>
> Cc: 68732@debbugs.gnu.org
>
> Suppose I am not a software developer but a system administrator. I prefer not to use the scratch
> buffer or M-:.

Then you should consider asking the software developer to write a
command for you which modifies the variable and then invokes
shell-command.

> If the variable shell-command-default-error-buffer is not interactive by design, how am I supposed to
> get a clean output from M-! grub-mkconfig RET, for example?

By writing a new command which does that and is otherwise a thin
wrapper around shell-command, for example.

> The design looks inconsistent in that the variable affects only interactive behaviour while being
> non-interactive itself. What is the use case for it? Who is supposed to modify its value?

Variables that are not user options are supposed to be modified by
Lisp programs.

(But I also fail to see a problem with using setq by users. It isn't
like that is forbidden or "not kosher" in some way. We even show
examples of that in the user manual. So why is this such a big
problem?)