I see the next important step as making the general cases easier to handle. A per-thread context such as IOhannes and Peter describe above seems like the best approach to allowing a program to run multiple instances of pd in a much more predictable manner, while it still allows for backwards compatibility (via a default 'legacy' context). I see parallel processing as a different topic, although it will be easier to implement once the static variables are taken care of.

Actually, I would sum up the thread slightly differently. We've touched three different topics: support for multiple instances of Pd, a potential refactoring of Pd on top of a library like libpd, and support for concurrency. As I see it, those three issues are largely orthogonal to one another. In particular, I'd rather not entangle multiple instances with multiple threads.

As far as libpd is concerned, the most important part is to achieve support for multiple instances. Tying instances to threads wouldn't be too helpful because there are lots of legitimate use cases where one thread needs multiple instances, as well as use cases where one instance is shared between threads.

The next step would be a refactoring of Pd, towards a more portable user interface. There's been an ongoing thread at Pd Everywhere on porting the UI to mobile devices (http://noisepages.com/groups/pd-everywhere/forum/topic/cross-platform-mobile-ui-for-libpd/?topic_page=3&num=15), and I wrote up a few thoughts on my blog (http://nettoyeur.noisepages.com/2012/01/refactoring-pure-data/).

Support for concurrency comes in third on my list. I already outlined most of my concerns in previous messages, and I also figure that this should be tabled until the other two problems have been solved.
Cheers,
Peter