What resolution would you play PA at?

I am going to say something that has never been said on the internet, ever.

... I was wrong, and you have persuaded me to your side of the argument.

1080p is gay! 1680 by 1050 FTW!

5760x1080 Is my current Display Resolution

1920x1200 unless I get a 30 inch @ 2560x1600 before PA comes out.

To the original question:

7680x1440, unless 4k screen become affordable.

I couldn't find a graph of it on Steam, maybe I didn't look hard enough, but here's one I made of their August 2012 data:

Speaking of windowed mode, I think I heard online or during the livestream that PA would use a multiwindow system for multiple/single monitors similar to SC's multi screen. Can you describe the intended way this would look/work?

2880x1800 >: D soon.. soon my retina x)

1680x1050

I would imagine this would be like split screen in SC, only with more splits.

Whatever my Nvidia 7600GT will push to my 1080p TV...
I need a new graphics card...

Yes. There's plenty of GPUs below $100,- that will outperform that one.

Heh, as soon as I need one I'll get one, it just happened to have the interface I needed at one point and was laying around my room.

I understood it as running multiple, synchronised, instances of the executable.

Why develop their own window manager when the OS already has one?
As I understand it 'Full screen' mode is just a cosmetic thing these days, simply a special case of maximised a window that hides all the 'bars' (title, task, status, etc).

I still dont know if my computer will support an good resolution.. I guess I have to buy a new machine just to play this game =)

I'll probably be playing on 1920x1080 and 1600x900 at the same time

Because communication between multiple processes is a lot harder than it is to communicate within 1 executable and almost always adds extra overhead. For example, to synchronize 2 threads between 2 processes you need at least 9000 cycles because you have to reach into windows' kernel, to do the same within a single process it can be done in less than 100 cycles.
Also, it is easier to catch input in a single process instead of catching it in multiple windows and constantly having to remember if the mouse/focus is in a certain window.
You might say it's possible to open multiple windows from a single process. This is true, but you'd still have the problem of catching input and it complexifies code. (I have tried this, it's no fun.)

Rendering also requires all assets to be contained in the GPU's memory and afaik multiple processes cannot share the same GPU memory. This would cause the game to have to upload all 3d geometry and 2d to the GPU per-window.

This is quite often not the case. What you're referring to is called borderless windowed and it's still often listed separately. You can easily notice if a game uses borderless windowed as it's fullscreen solution because alt-tab is instant with borderless.

In a client server-model the clients don't need to talk to one another just the server.

Short answer: You truly believe it's faster to communicate with a server multiple times than it is to communicate inside a single process?

Long, better answer:
So you would have multiple windows on a single computer all use the internet to connect to a server.
This adds even more overhead because each will have to send packets to the server and receive responses, each taking up network bandwidth, server CPU cycles and your own CPU cycles, because sending or receiving packets takes CPU time. Having to wait for packets from the server means you lose at least 16 ms.
With 1 million CPU cycles per ms (per Ghz you have, per core you have, so for a 3.5ghz quad core that's 14 million cycles per ms), you want the game to have as low a ping as possible, especially with the client-server model, as each client will have to wait for the server to do simulation before they can render it to your screen (or screens).
The game might be able to do some prediction, this is true, but this means adding multiple processes on the same PC will increase CPU strain because they cannot predict once and easily share the results.

Even without the interprocess communication problem (which is still there), having a single process would still be more efficient (because of the other things I've said) than having multiple.

Please show me where I said or even implied that?

Of course it's a less efficient use of PC and network resources but it's also a great deal less development effort than coming up with some form of proxy, scheduler, etc. managing the interactions between individual windows and the server.

It would essentially behave in much the same manor as multiple users sharing control of a single force.

Coding elegant and efficiently solutions to problems is all well and good.
But if simply throwing more hardware resources at a problem solves it easier and cheaper then to do otherwise is just an academic exercise.