Just the minimum 2 cents as i am not a 'stakeholder' or power user or anything.
Making the separation between the server and the client seems to be a very good idea and one of the next steps for pd to take. It seems that no one is even arguing it, and if really not, we can soon take it agreed. (Rien ne va plus...? ;o)
When we arrive to having an API, it will be easy to make up GUIs in different programming languages based on different GUI libraries. The question is, would the makers of the 'official' GUI be willing to make the switch or they'd rather continue with a Tcl/Tk one? I wouldn't be surprised by either choice, but i think the earlier we know about this, the better we can plan for the future.
I don't know much about desktop application development, but i have a clue that using any of the beforementioned GUI kits we will have to write up our own canvas widget which will take much part of the overall process. (Even more that it seems the GUI will have to take over some of the tasks that are currently done by the C backend). I would also like to ask whether people who are familiar with these *fast* GUI kits are confident that the canvas widget that we make up will be *fast* enough too. (I am sort of familiar with the problems of the Xara X graphics program which is written with the fast WX kit but the tumbling block is that single canvas object which had been written *into* WX and which is very fast but copyrighted, and no one sees a way to write up a similarly *fast* one).
It was also mentioned if the client and the server shall be linked (at compile time). I'd suggest not, but there may be need for API versioning - something like Jack has. So we don't have to work out *the* perfect API *before* we could start using it, but some evolution with time is allowed.

Andras