I think a better way of doing this is probably to hack the scrollbox dataprovider, rather than SetText, and let Blizzard do all the layout.

E.g.,

local function ReplaceProvider(frame)
   local i = 1
   
   local dp = frame.GreetingPanel.ScrollBox:GetDataProvider()
   
   for _, item in ipairs(dp.collection) do
      if item.buttonType == GOSSIP_BUTTON_TYPE_OPTION then
         item.info.name = i .. " " .. item.info.name
         i = i + 1
      elseif item.buttonType == GOSSIP_BUTTON_TYPE_ACTIVE_QUEST or
             item.buttonType == GOSSIP_BUTTON_TYPE_AVAILABLE_QUEST then
         item.info.title = i .. " " .. item.info.title
         i = i + 1
      end
   end
   
   frame.GreetingPanel.ScrollBox:SetDataProvider(dp)
end

hooksecurefunc(GossipFrame, 'Update', ReplaceProvider)

Unfortunately, while this is a very clean solution, there is no equivalent DataProvider for QuestFrame stuff, only for GossipFrame stuff.

Luckily, there was a fix in the original DialogKey that we overlooked when making the current SetText() code!

Nevermind, that fix only works for QuestGreetingFrame grumble grumble.

What is the fix? I made (prior to your comment) a version that used DataProvider for the GossipFrame and left QuestFrame different:

xod-wow@4c10c63

Perhaps we can combine?

Edit: To be fair I have not exhaustively tested it as working in all situtations.

QuestGreetingFrame uses a TitleFramePool for the buttons, a consequence of which is that the buttons are anchored to each other like a ladder. The fix for the overlapping text there is to just increase the actual height of the button, which you can see done at the bottom of the current code's EnumerateGossips function.

Edit: This doesn't work for GossipFrame options as these buttons are anchored to the window itself it seems, so they use absolute positioning inside of the ScrollBox.

As I type this I've got a slightly modified version of your DataProvider hook (which is way cleaner than the DataProvider hack @N0ich had in the code before, which we inherited from the original addon) in my local dev code that I'm gonna push in a moment.

I think it may need some kind of already-enumerated flag. I suspect it's possible in rare circumstances for it to double-number (or I guess in theory more).

I'd be surprised if it did. I've occasionally seen QuestFrames trigger an update that clears the modified text, so I suspect that the Update event you're hooking to clears the text entirely and rebuilds it from... wherever it gets the labels originally.

I modified EnumerateGossips to not double number GossipFrames, though :P

Appreciate your fixing this

This is great, thank you