Goto instructions are quite problematical, since the target instruction could be in an instruction sequence which is not even being executed. Furthermore, any number of procedure/function activations may have to be terminated.
By far the best solution seems to remove goto instructions from the language being implemented.
However, if goto instructions must be implemented, it can be handled as follows (assuming that language rules subject labels to normal scope rules, with nested instruction sequences treated as nested scopes and therefore not visible).
Case 1, the goto instruction targets another instruction in the same sequence: This goto can be translated into a goto of the target language. If interpreted, a flag can be set with the name of the target label. Walk_instructions would have to check this flag after every instruction and select the next instruction appropriately. Something similar to a hardware instruction counter can be used.
Case 2: the goto instruction targets an instruction in an outer instruction sequence: This goto can be handled similarly to a multi-level exit, while proceeding as in Case 1, once the appropriate scope has been reached. Quite a lot of coordination must be provided in the methods modeling loops and function/procedure calls.
If it must be possible to target labels in nested scopes, quite a bit more work must be done and a lot depends on the actual semantics of the language. For example, what happens when you jump into the middle of a for loop?
Since one is modeling the semantics of the language, rather than specifying its translation into another language, it is inevitable that constructs with complicated semantics will be hard to implement using the methods outlined in this text. This is not necessarily a disadvantage.