Well, after solving it, I have to say that this is indeed an actual issue, that blocks correct solutions. The issue created by papersaltserver does indeed highlight the problem but it's marked as spoiler so it's hidden.

I don't believe it's a spoiler, since it doesn't show how to solve the kata, only how to properly manipulate the solution and return the data in order to pass the tests.

Hello, I'd like to request for this issue to be unflagged, it's not a spoiler, it's a problem with the tests. It's nearly impossible to solve it without knowing that.

This problem actually blocks correct solutions, I'll try to explain why below:

If you convert every single byte and append it to a string (like we do in other languages) and then return that string, it fails.
If you append them to a byte array and then convert the whole thing to a string, it passes.

If I had to guess, that's probably because when it handles individual extended ASCII chars, it converts them to the "\uFFFF" format, but for some reason when they're part of a slice/array conversion it leaves them as "\xFF"

Every conversion I've tried so far results in -> "\u0086" where the tests require ->"\x86".
Casting with string(), converting with strconv and fmt.Sprintf all produce "\u0086".
Trying to create a new string results in "\x86".
Any hints you can give me ?
In Java I encountered no similar issue and solved it in a few minutes.
(Now that I can see the hidden issue, it's the same as my question)

The expected behavior is undocumented and inconsistent across the languages. There already are a question and an issue about it below.

Also I'd like to add that printing "\x86" results in � which is the Unicode replacement character for invalid codes.

In Go: The randomized tests keep asking for things like "\x86" while the result my conversion to string gives me is "\u0086". Through testing I've discovered that they both correspond to 134 but having tried multiple ways to convert to string I've failed to get the format "\x86". Also replacing "u00" with "x" results in a string like this -> "\x86" and I'm unable to remove one of the backslashes. Removing a single backslash, removes both of them.

Solving the same kata in Java was actually a piece of cake, the Go version is driving me crazy. Any suggestions ?

Yea, I wasn't sure if it was an issue because solving it in Java was really easy. But the same solution doesn't work with the randomized tests of Go and I was wondering at the same time if there is an issue with the tests.

The "Issue" tag is for confirmed problems within the Kata itself - please use the "Question" tag instead if you are having a problem with your own solution or are unsure whether the problem is in your solution or the Kata itself.

Go: In the random tests, I keep seeing parts of the string that look like "\x88" but I can only get the equivalent "\u0088". I've tried multiple ways of conversion to string, trying to get the desired result but they all failed. I've tried editing the string to change it to "\x88" but it always results to "\x88". Any suggestions that could help solve this issue ?

It's more fun when you do it yourself.

L2debug your code

This kata is only worth it if you don't use any packages. It was the first one I did and I was kinda disappointed when I saw that the use of packages is permitted. There should be an option to disallow the use of packages, in order to make katas such as this one worth trying.