This use case seems to me an excellent example of why shutdown/flush should
*not* be in SLF4J. It's characteristics are as follows:

1) It is explicitly about application lifecycle, specifically about how an
application stops. As such it's perfectly reasonable for the code that starts
and stops the application (and hence *must* depend directly on a specific SLF4J
implementation) to know about that implementation and use it. Logback, for
instance, has a means to shut it down - this can simply be used in the context
of application ending code.

2) It is explicitly about *how* log messages are handled (in this case, sent to
standard out). One of the basic ideas about SLF4J is that it knows nothing
about what happens to a log message and its arguments. They may be discarded,
they may be sent over a socket to some other process, they may be sent to a
database, they may be held in memory - that's all the business of the
implementation and its configuration, *not* SLF4J.

To me a great deal of the value and flexibility of the SLF4J interface lies in
how little it attempts to abstract over. It does not seek to abstract over an
entire logging implementation, only over the basics of sending a log message to
something unknown that may do what it likes with it. The primary use case to me
is libraries, that do not know what application will bring them in or what
logging implementation it may be interested in or how it may seek to output its
log statements. That's all a different concern.