A publicly published copy of a local function reference would do just as well, but wouldn't let mods override the token generation to user's tastes. I prefered MobName(number) for example, instead of a letter suffix.
Currently, CombatLog_String_GetToken() is in _G, publicized on line 2116 of Blizzard_CombatLog. Is that insufficient? I understand the current mechanism prevents function hooking to change functionality.
Bam is correct. Using a local will prevent hooking of any kind. Generally speaking, locals are both used for execution speed as well as code protection. In this case, code protection is unwanted here.
In any case, I recommend Zeksie NOT to rely on any function in the Blizzard_CombatLog as it is LoD, and as with any LoD addon, they can be overriden not to ever load by another Combat Log addon that the user can choose to make (that's why it is LoD, to allow it to be overriden). Yes, this means I am recommending Zeksie to rewrite the Grim Reaper module.
For this particular reason, Antiarc and I have moved out all the combat log constants out from FrameXML\AddOns\Blizzard_CombatLog to FrameXML\Constants.lua so that other addons can use these constants without copying them or forcing Blizzard_CombatLog to load first.
A good example of this is the old SuperInspect. SuperInspect replaces the Blizzard_InspectUI and prevents it from loading.
However, the part about locals preventing function hooks to change a small behavior by a small addon to the default combat log UI is true, and I'll discuss this with Antiarc/Alexander.
Yes, Antiarc and me optimized the whole Blizzard_CombatLog to use a lot of local upvalues instead, its quite apparent that the last commit was almost a direct .diff file generated from my last commit without edits to remove some of my comments.
Hmm, Zeksie, what are you trying to do? I'll get back to Antiarc and Alexander about un-local-ing some of those things.