Question: Fencing tokens for storage

What is your question?

When implementing a storage backend the comment describing Lock() mentions the use of fencing tokens:
https://github.com/caddyserver/certmagic/blob/9826a4c3549441ba6dddcfc5d561f097feb44e2a/storage.go#L108-L112
The way I understand this is that once you have the lock further interaction with the backend while holding the lock, like writing a file, should then include such a token so that the write can fail if the token is out of date.

What I am not understanding is this: given that Lock() takes a name, potentially meaning there could be multiple different locks held for different operations at the same time, how would I map a Store() request with the appropriate lock so that it can access the correct fencing token?

What have you already tried?

I have investigated the Store() call and from what I can tell the only information available to it is the key name and data that should be written.

Start with the Lock() comment in storage.go at the linked lines, then trace the Store() interface and its callers to understand what context each operation receives. The issue would be resolved when the fencing-token relationship between Lock() and Store() is clearly defined or the needed API change is specified.