No, my fix handles this well.
In fact, with the first function call you allocate global variables representing Python function input parameters, call the function and receive iterator over the function results. Then in a series of Postgres calls to PL/Python handler you just fetch next value from the iterator, you are not calling the Python function anymore. When the iterator reaches the end, PL/Python call handler deallocates the global variable representing function input parameter.
Regardless of the number of parallel invocations of the same function, each of them in my patch would set its own input parameters to the Python function, call the function and receive separate iterators. When the first function's result iterator would reach its end, it would deallocate the input global variable. But it won't affect other functions as they no longer need to invoke any Python code. Even if they need - they would reallocate global variable (it would be set before the Python function invocation). The issue here was in the fact that they tried to deallocate the global input variable multiple times independently, which caused error that I fixed.
Regarding the patch for the second case with recursion - not caching the "globals" between function calls would have a performance impact, as you would have to construct "globals" object before each function call. And you need globals as it contains references to "plpy" module and global variables and global dictionary ("GD"). I will think on this, maybe there might be a better design for this scenario. But I still think the second scenario requires a separate patch