Logger Composability Guidelines

This is not necessarily a feature request but maybe a request for guidelines. Currently a lot of crates provide something like try_init or init where a logger is set as the global handler. As there can only be one it means that once that happens nobody can change it (unlike for instance the panic hook which can be overridden).

As a result crates like sentry that want to get logger data in addition to dispatching to another logger run into the issue where the user needs to completely change their code to get it hooked. For instance the pretty_env_logger and many others do not even provide a convenient way to say "get me a logger with default config" but don't register it.

Would it make sense to encourage loggers to provide a standardized API that returns a logger but does not register it? A similar issue also happens with the global level where users themselves need to figure out what the highest level is that multiple loggers might need.

Start by reviewing the issue discussion and the existing init and try_init patterns used by logging crates. Determine whether the project can document composable logger construction and global-level coordination; done requires a decided, actionable guideline rather than an unresolved API proposal.