One problem of your implementation that I've found in the meantime is that you are not using the Throwable that might have been detected by ParameterizedMessage.

That's a bug. The constructor for LoggingEvent takes a Message and a throwable. If the throwable is present (meaning it was specified on the call) then it should be used. If it is null then the throwable in the Message should be used. The same thing should be done when filtering, but there the Message, if present on the api call used, needs to be decomposed into the raw message format and parameters so that calls that don't have a Message don't create one.

Fixing this problem is pretty easy.

I won't believe that until I see a fork of Logback that depends on your SLF4J implementation. It was very difficult to get Logback to accept the Message and deal with it correctly.

Well, you did the hardest part of the work already, i.e. the Message handling throughout the rest of the API.

I'd honestly like to have some input from Ceki because I don't want to invest too much time if all of this ends in a "nope".

If you notice there really is no extra overhead since in my fork Logback's getLogger() always returns a MessageLogger. It isn't really wrapped. No kludgy code is needed. Since MessageLogger extends Logger anyone calling LoggerFactory.getLogger() will work just fine.  The wrapper is only needed if a Logger implementation returns a Logger. Then MessageLoggerFactory will wrap it.

What MessageLoggerFactory? Now I'm lost. ;)

In my fork. Look at the org.slf4j.message package. With Logback the only difference between MessageLoggerFactory and LoggerFactory is that the return type is MessageLogger. A user calling LoggerFactory would still get a MessageLogger but the return type is Logger.

Ralph