One difficulty I see is forcing the loading of the intended SLF4JServiceProvider by org.slf4j.LoggerFactory. You will have clogr's provider and logback's provider and SLF4J will pick the first one it finds on the list.

Yes. That's why in a perfect world, each SLF4J implementation should be divided in to an "SLF4J implementation" component, and an "SLF4J service provider" component. That way a library could pull in an SLF4J implementation to delegate to it without automatically getting the implementation picked up by the service provider mechanism.

In this way Clogr could expose itself as an SLF4J service provider, and then delegate to whichever SLF4J implementation it wanted to—and even have multiple SLFJ4J implementations configured across the application. In fact then Clogr wouldn't even need a LoggerContext framework, because it has its own built-in.

This distinction between "implementation" and "service provider" is the way Clogr partitions its own artifacts. But that's not the way Logback (or any other SLF4J implementations partition their artifacts). So we're still left with a need for a service provider framework for the LoggerContext.