Never write solutions for "potential" changes. The code should do that what is needed and nothing else.

Its a very good point from Rainbowkatz

//return output
return output

now that's a helpful comment lmao

But the problem isn't different, the problem is what it is and this solution is extremely clever and efficient.

Nice. I prefer my solution because it's clear what's going on.

Nice! Checkout my solution, I believe it's faster.

Raised as an issue.

Thanks. I admit that in the course of my day-to-day I don't leave such detailed comments but here I figured maybe someone could benefit from them.

Refreshing to have comments in code

There is an issue on the attempt in Go. It's failing when nbBear is 9 and yet the length of the whole pair output is 10, meaning only 5 pairs. Therefore, should be false, not enough but it's failing the attempt saying it should be true.

Yeah, you are right. Sometimes i choose the easy way.

Nice but the initial ToLower is a full iteration that's not necessary as you can just convert each rune to lowercase in your first for loop

Super clever but I don't consider this best practice since if you change any part of the problem this solution becomes useless. For example, if multiple numbers could have odd counts or you were asked for a specific count like 2, 5, 7, etc. Super clever though.