GET_LOCK([name], 0) behaviour and multiple GET_LOCK() order
OBSERVATIONS
In your question, you said

I read from the documentation that the behaviour of distributing a lock requested by many connections after RELEASE_LOCK is called from the connection holding the lock is undefined.

You are overlooking something far more basic
MySQL Documentation clear says the following on GET_LOCK()

A negative timeout value means infinite timeout.
If multiple clients are waiting for a lock, the order in which they will acquire it is undefined. Applications should not assume that clients will acquire the lock in the same order that they issued the lock requests.

The Documentation says nothing about a zero(0) timeout value. Thus, that behavior, in itself, is simplified. If it acquires the lock, it immediately returns 1.  If it does not acquire the lock, it immediately returns zero(0).
You said p2 has a 10-second timeout (because you said you are using GET_LOCK(&quot;lock&quot;,10)).
If you are expecting p1() to pause execution, using a non-positive will not accomplish this.
SUGGESTION
You may want to execute a loop in your Stored Procedure to attempt to acquire the lock with some arbitrary number of seconds to pause between lock attempts:
SET @seconds_to_pause = 5;
SET @lock_acquired = GET_LOCK('lock',0);
WHILE @lock_acquired = 0 DO
    SET @x = SLEEP(@seconds_to_pause);
    SET @lock_acquired = GET_LOCK('lock',0);
END WHILE;

Give it a Try !!
YOUR ORIGINAL QUESTION

is it possible for the lock to be passed down successive calls to p1 and p2 has to wait?

If you do not have a loop to acquired the lock as I suggested,the answer would have to be no.