Thank you for creating this Kata. The description is sufficiently detailed, and the graphical output is a neat tool to "play" the game in order to understand it.
The only question remaining was whether the game map will always be rectangular (I think it always is), so the symbols +-|# effectively mean the same.
The test cases seem sufficient; please do not modify the total number of test cases, as this Kata is performance critical (naive solutions still should time out, but previously successful solutions should not).

It would be nice to have an overview over all possible options given to ArrayComprehension, instead of having to search through the instructions of the predecessor katas.

I enjoyed this kata very much. The only thing lacking in the description is which objects may be accessed from where:

• Is is allways possible to create variables by assigning to them (e.g. 1+(x=2) with x undeclared)?
• May functions access global variables (according to the test cases, the global variable z should be rejected as unknown)? May they access other functions? Should there be a test for loop-calls (since it is not possible to terminate recursion)?
• Assume function A is declared to call a function B. If A gets redefined, which function B should be evaluated when A is called? What happens, if the redefined B has a different number of arguments?

The test cases can be passed by short-cutting many features of the language. Functions calling other functions don't need to be supported to pass the tests as well as functions without arguments. The simplest solution just would switch-case the finite number of test cases and return the appropriate result. My solution rejects ' ' as input, which seems unintended.

There should be at least one randomized test, preferably with functions having an unpredictable number of arguments and in unpredictable composition. Eventually, the interpreter should reject an input like '1 2', which is currently not tested. e.g. in my solution, parsing is done as far as possible and then the result is returned to the caller. The outer function must check that the whole input is read. If I left this check out, the result of evaluating '1 2' would be '1', but throwing an error makes more sense to me.

The first list of attributes should contain the correct names and therefore no spaces (e.g. ballCount or ball_count instead of ball count).
This issue also applies to the methods' names.
The list of attributes is also the best place to explain the initial values.

The attribute ballType is explained in a code example, I prefer a sentence (e.g. 'Balls are objects with an attribute ballType, which has one of the values "regular" and "super".'). Code examples are good in addition to whole sentences, but the sentences should explain everything.

Taking the description literally, eating a regular ball with superTime=0 yields superTime=-1. This behaviour seems unintended although it passes the tests. Resetting state to "regular" when superTime <= 0 should also be mentioned in the explaination of the eatBall-method. Again, the attribute is called 'superTime' or 'super_time' and not '"super time"'.

When referring to the Pacman object's state in the eatGhost method's description, string values should be expressed consistently either with quotes or without.

The description tells, resetting the points to zero should be done, when the attribute lives reaches 0, but the test cases expect -1. There should one value be choosen and then mentioned in the description and tested in the test cases.

I prefer throwing an exception when the lives get that low (0 or -1). I can hardly imagine an application of a Pacman object with negative or zero lives, having possibly a positive ballCount and ghostCounts, being able to eat ghosts and balls, having no points, but beeing able to earn them (since it can eat balls) and loose them by eating ghosts, which will decrement lives further. A "Game Over"-Exception could indicate the Pacman Object should no longer be used and would make more sense to me.

Eventually, the test cases for python apparently need a revision. Whatever I submit, I get the error

 should equal 

When this list of issued is fixed, it will certainly be an enjoyable little kata.

Understanding this kata was the main problem for me. A brief overview about sequences, generators etc. (as given in part1, which I looked up for these details) would be nice.
It wasn't easy to figure out for me, whether I should give a result, or a function returning the result, or a function returning a function returning the result.
When I understood this, the kata was nice.

1 is not a prime number and therefore should not be expected to occur in the prime numbers' sequence.