Note the "Solution setup" contains invalid Go code - look at how every solution modifies it.

"func Add(int)" is invalid Go/Golang code - notice how every solution modifies the starting code.
The problem description uses the variable name "n", so the starting code should match the description:

func Add(n int) func(int)int {
// your code here
}

I can sympathize - I spent more time debugging the "msg" instruction than anything else. My first attempt using Python's "re" module didn't go well. I wound up writing custom code to deal with it.

As to finishing without an "end", yes that should cause -1 to be returned.
Any error or problem results in a -1 return value.

My goal was fast execution of the code, so I moved as much effort as possible into the parsing step. That was probably influenced by the prior kata in the series where some lines get executed hundreds of thousands of times. In situations like that, parsing pays a great dividend.

There isn't really a good phrase that covers both a switch statement and dictionary - delegating? Maybe the "delegating instructions" step, where an advantage of the dictionary to function approach is the speed of execution.

I didn't encounter debugging hell with the OOP approach, but maybe asserts in the right places and having an intuition for what could go wrong helped.

The meaning of \n is undefined in this langauge - you're assuming it must become a newline.

In case @qmstuart is curious about situations not covered in the tests:
The code after the label 'function' would run twice, and hitting ret a second time would be an error.
When the program stops without hitting an "end", it should return integer -1

If there's an error in the program, you should return the int value -1

There's no whitespace in register or label names.
The tests don't seem to call msg twice - my code inserts newlines when it sees repeat calls.

That testcase looks familiar: I think the inner loop executes over 300,000 times.

I agree with hobovsky's interpretation. In Go, accessing a map evaluates to 0 for missing elements. For the source code of "jnz 1 5", case "jnz" performs a lookup res["1"] which doesn't match any named registers. That evaluates to zero, and causes "jnz 1 5" to do nothing. The expected behavior is to jump +5 instructions.

Did you see the part about "Debug your solution"? There is a link to another document that starts with:
"Most (all?) languages on CodeWars support writing to standard output. You can use stdout functions of your language to print function arguments (or anything else) and it will be visible in test output panel."

It's harder to debug if you don't reveal which input caused your test to fail, plus the expected output and what your code actually produced.

What happens when you print out the input string? Can you see why it's failing?

The tests expect the name "FirstNonRepeating()" to exist, but the initial code defines "firstNonRepeating()" instead. I would up defining both methods just in case.

Where did you get that example?

For that case, yes "a" would need to overflow until it hit 0 to fall through the "jnz a -2" instruction.

Execution lands wherever the jnz says, skipping over other instructions.

jnz +1 +2
dec a
inc a

The above code skips over "dec a" to perform "inc a". The +2 is relative to the "jnz" line, and +1 is always non-zero.