For context, like I said, your solution is good and I probably would use something like it, perhaps I even will in the future. Where my comments come from is that as I read people's comments around using Go generics now that they are here now, I'm beginning to wonder if a great deal of the mismatch between the Go community's attitudes towards them and the external community's attitudes towards them is that a lot of people bounced off of X thinking "it just can't be done", when in fact it could, perhaps just not as well, but not necessarily "not as well" as people thought, either.

I don't have 14 instances, but I do have a few places where I have 6 or 7, and they mostly ended up copy&pasted blocks, and I sweat about that a lot less than I used to because in the end the question isn't whether you end up with repeated code at scale but how. Your mileage may legitimately vary. My larger concern is more trying to figure out how to help people understand how to do things in general, because even if the technique isn't useful enough here it's still the answer to a lot of Go problems. (And, for that matter, a lot of FP problems. They use a lot of "just functions" over there.)

"I'd be interested to know how you were bitten by it in the past?"

I mean it as a general warning, because your specific case is fine.

But I've been bitten multiple times by people thinking this is a great encoding scheme to use in key/value stores where they also use underscores in the values being encoded. Bear in mind the person writing the "%s_%s" may not be the person choosing the other values being used as keys, and may have simply been using the key/value store as a magic box that stored things for years.

So if someone writes some code and the key "msg_value_by_author"... where exactly does it break down? Even as a human, stripped of context, you don't really know. The real fun is when multiple bits of the code decide "oh, it's just a string, I can parse this myself, we don't need library code" and then of course the bit of the system that sent in "msg_value" writes a workaround for their own parsing, that other bits of the system don't get.

Is it a mess? Heck yes. Should you not write that mess in the first place? Of course. Has it at times been a persistent thorn in my side anyhow? Oh yes.

As you have it written now, no, you really shouldn't have a problem, and even if you do, it'll be brief. But it's still good to know you've got code that is, shall we say, "problem adjacent" and it doesn't take much for an intern to come in, see that, and make a "small tweak" that turns out to be a long-term problem. And also, I'd like to put that idea out there for other people so they can also keep an eye on it.

If you instead consider the format string as an encoding scheme into which you must encode the two values in an unambiguous representation, and it so happens that the XIDs are always unambiguously encoded by performing the null transform on them, you're better off then thinking about them as strings that can always be separated by a random other string safely. Done correctly, this is quite safe and you can jam quite a few strings into something like a Redis key without having to worry about what they may contain.