I like this solution:

1. just 30 lines, compared to my 200 lines...
2. understandable coding, nothing to "genius", just well thought trough (wheras my own is just a clumsy implementation of all stages in a process)
3. I learned something new from the line: ys, xs = zip(*alive)

• it gives us an iterator of 2-tuples - AND - we can dis-assemble this iterator into the components of the tuples - that is new to me and a very nice property - no fumbling with a list of pairs, as we would have gotten from something like "list(alive)"

4. the double/tripple for-loops in the comprehensions - I have never seen this before and would never have thought of doing this myself, again a lesson learned!

If I log out the input array after the method has run, I get the same as before, i.e. the input is not changed.

Well, yes: hurts to look at...
but every other solution (including my own) does so too: fiddling with minus and space and bla

Still some nice things to learn from this one...

Comments would have been nice, however, this is a great solution in my opinion. Especially when compared to the monstrosity I came up with. I am somewhat of a newbie and I could understand the solution. When I see a solution like this I wonder what my mind does during the process of determining the best way to work this.

Some problems are inherently mathematical. And often, a mathematical solution is necessary, otherwise the computation is intractable. You might like to know that computers were basically invented to solve mathematical problems that had undergone 'mathematical transformations'.

Perhaps I'm to picky here: like most of the solutions You reformulate the conditions, i.e. You calculate the negations somewhere, in Your head or a sheet of paper and test for these calculated conditions - which in this case is easy enough. In general I don't think that this is advisable: it is prone to error, and everybody maintaining your code has to do these calculations in order to check if they are equivalent to those in the specification. I think it is better to test for !(h>0) as specified, instead of testing for (h<=0).

Ok, I would have thought that You are proficient, because of the prime-number stuff... Unfortunately I do not know about a way to generate primes, i.e. every algorithm like yours has the limitation of just finding the right answer for the primes you included - and for all of their possible products of course. Probably execution-times are very low, since you are only checking for the primes.
My own algorithm is much worse - though it passed the auto-grader... But - in the end we are here for learning, aren't we?

Oops, right. I wasn't sure my solution would always work, but I trusted the test cases (am in no way proficient in maths).

Is it genius ? Is it madness? - I would refuse to maintain such code. If I absolutely had to, I would delete it and start afresh, not wasting my time to try to understand it. At least a few comments to explain what is done should be given.

Yes, You are right - realized this the other day, but could not find my comment to Your solution to correct myself.

If I understand the Kata correctly, item_index itself is also a zero based index, so:

item_indexes 0, 1, 2, 3 should return 0
item_index 4 should return 1

n=2048 : should [2, 11] ---> get: None
Nice idea to use prime powers only, but keeps the algorithm from working when k consists of primes not in your list.