Definitely 7 kyu in my book. But I'm far from being an expert in rating katas.
BTW, IMO basic threads and synchronization primitives should be a part of basic knowledge for all developers anyways. Somewhere next to using iterators and handling exceptions.

Thank you for the feedback. The test cases were actually already checking for the case of nil. I've added false to the list of possible values to check. When you run the acceptance tests, you see what memoized values they are checking - nil and false should be there, you can verify yourself.

:) Good. That means, this excercise was not entirely useless. :)

Shoudld be fixed now.

Added. Thank you.

Thanks! Fixed.

Agreed :) Just a habit, I guess.

For some reason, I can't add more tags. May be I'm doing something wrong, but the tags I set in the description don't show up eventually for the kata.

Thank you, Dr Phil. Glad to provide some entertainment :)
I replaced "a" and "b" with "s" (for "slope") and "t" to avoid (hopefully) such confusion in the future.

Thanks for the comment, Tuhaj. Updated, though I believe that this is not the place to introduce new concepts. To the new programmers it should just remind that there is such thing as threads, and if they want to solve this (very-very basic) kata they should read about it. Writing a test case themselves is as important part of the learning process as solving the problem. I always add sample tests for more complex cases, but in such simple ones I often leave it to the reader. Anyways, I may be wrong, so I added a sample test case, an example to the description and two pointers - to Ruby Threads module and to the wikipedia page about threads.

The test provided as a sample (see below) is useless. giftwrap method is not available to the person solving the kata.

Test.assert_equals(42, unwrap(giftwrap(42)))

Too bad, it was fun :)
And I see you removed some honor from me for my 2nd solution of this kata, which obviously also always passes.

A bit surprised that nobody has already tried to play with what I did in the solution to this kata (which worked). Kinda one of the first things that come to mind that you think about how to deal with that.

Or, is it just me and my troubled childhood (system-level stuff, inter-process communications) ;) is what played its role in the priorities here?

On a bit more serious note: are we protected from that trick in other katas? Guess, not (Don't want to check to avoid being caught as a cheater later). If so, should be addressed IMO, or else it's too easy to gain honor through this exploit.

On a related note, is it OK to mention the Codewars kata solutions in educational blog posts & screencasts? Like in: "Here is a nice functional way to find all hashtags in a string, inspired by a CodeWars kata solution: <some code>".

Some of those 1-liners are elegant enough to share as "best practices" or "clever" with the rest of the world. Of course, it can be done without a reference to Codewars at all, but it is usually better if the credit goes where it is due (and attracts more interest to Codewars in this case).

How do we flag the potential cheaters now? Do you have any review system for reported cases?
If the only solution to my authored kata is identical to mine, and it's a 20+ lines class, that seems suspicious to me, I'd like to flag that somehow for review.