This is caused by
PHP:
UseItemRequest.retrying = true; // prevent recursing more than once
in UseItemRequest.
That whole mechanism looks a little suspicious to me. I think rather than setting a "retrying" thing, we should do something to inform the ChoiceManager to immediately use another gong after it actually gets the Welcome Back.
Under "normal" circumstances, you could chain a flashback, arrowed monster, nemesis monster, and FoB monster all before you get Welcome Back (if you have a stretch of non-adventure.php adventures, you can trivially force all but the flashback).
...which would solve this. But, do we really want KoLmafia to repeatedly auto-adventure in the Newbie Cave - and be shunted elsewhere - until it gets that choice? Given that we are doing this in response to the user attempting to "use" a gong, I guess so - but this seems dangerous.
However, mafia assumes it will take 0 turns and causes counters to be ignored, which is a problem when it actually does take a turn and would be more of a problem if multiple turns were spent.
... especially for this reason. Which is more of a problem: having your counter script fire (or have the counter removed) before adventuring, since the Newbie Cave adventure MIGHT (although almost never will) take an adventure, or assume that it will take no adventures, go to the Newbie Cave, and discover that it took an adventure and a turn was taken?
If you were right on the semirare counter, say, you should probably try to go where you wanted to go. That will either trigger the Welcome Back adventure or - assuming the other events can override a semirare - you will lose your semirare anyway.
This looks like a can of worms. Would it be a problem if we simply refused to use another gong if you haven't already gotten Welcome Back, rather than trying to go get it and then use a gong? How, exactly, are people using this feature?