On a vt switch, greetd always redirects stdout and stderr to the new vt.
On graphical sessions this means that the output ends up under the
framebuffer, mostly inaccessible without some slightly awkward shell
redirections in the session command.

I would like to suggest the addition of a flag that persists the stdout
and stderr of the parent process, so output can more easily be captured
and redirected to logfiles. I have managed to patch my own local version
of greetd to allow this behavior, and I'm more than happy to submit this
patch if there's agreement that this feature is welcome. Although this
patch is a little messy as it has to pass a boolean between every
function in the path from initializing the config to spawning processes.
Which leads me to wonder if the current config handling should be
replaced with a lazily-evaluated static.

Why not just redirect stdout wherever you'd like from the session commands?

One issue with an option to control stdout behavior is that a greeter 
can start a text-based session (which requires stdout to be wired up 
correctly) just as well as a graphical session (where you want this 
behavior), all through the same API.

This would then require communicating the "mode", which in turn means 
that it must be selected. This might make sense for some greeters that 
use .desktop files (e.g., QtGreet), but not others (e.g., agreety and 
gtkgreet). On the other hand, as long as the "console mode" still works 
as a default...