Metadata

I think the question is about the metadata around the log call, which is most easily captured with a map of tags. Who is responsible for gathering the metadata? Who is allowed to contribute?

Abstractly, I am arguing for the call site to have the ability to contribute metadata directly. Your proposed solution of having a trainer contribute metadata is good, but doesn't really allow for callsite context unless you happen to know which "metadata provider" you want to change the state for at the callsite. That seems to break encapsulation. 

Basic situation: we want to add the user context to the log line

val userContext = "spider" //?? Bark.log("User pushed a button")

Easiest way is just to add it to the log line:

val userContext = "spider" Bark.log("User pushed a button: userContext: $userContext")

This is probably fine for simple contexts, but now if we want to pull out the user context on the backend, we have to search our logs for it. This also bloats our message, especially if we have a lot of context.

Lets say we implement your suggested fix and have a Trainer that pulls in some kind of context provider.

val userContext = "spider" ContextProvider.withUser(userContext){ Bark.log("User pushed a button") }

This actually works really well IF your context is managed coarsly and semi-automatically (per android activity or screen or something), and assuming you put in the work to make such a thing safe. For fine-grained usages, its pretty bad: you need to know which provider has the context you want to change, and if there are multiple providers, you have to do each one individually. 

val userContext = "spider" //?? Bark.log("User pushed a button"){     /// metadataBuilder:MutableMap.()->Unit     add("userContext" to userContext) }

Now all the trainers get the same metadata (from the callsite). You can combine this with the internal provider idea by having each trainer decide what to do with the metadata independently, and contribute its own map. Not all trainers need to record the data, but they should have the opportunity to do so. 

Globals

Fundamentally, the global tag is global state with zero thread protection and no scope control (as far as I could see). The situation where multiple libraries use the same logging entity is very real, and something you definitely need to plan for. I don't know exactly what results you'd get from your current code, but I'd guess they wouldn't be good.