Google Chrome is just as bad if not worse than xmms because it's so loved; I'm a firm believer that user interface improvements should be shared between programs rather than implemented as one-off exceptions to the system setup. If it's a real improvement I'm bound to want it elsewhere, and if not, the loss of consistency isn't worth the small gain for that particular application.
Still not as attractive as Firefox, to my mind, but that's opinions for you.
How? I didn't know this was possible and tried it (after some googling). Basically I have two choices: bad and worse. The default has the tabs on top. If I enable "hide system title bar", it adds a frame with close, minimize, maximize buttons.
I use a window manager with no decorations, just 1px border around active window. I'd like to get rid of the Chromium custom ugly tab bar.
I still want my tabs inside the browser (my wm doesn't have tabs for every window like ion3 or kde kwin). However, I don't want the tab bar to be visible unless I'm in the process of changing tabs with ctrl-tab. Same goes for the address bar, I'd like to see it only when I'm typing to it.
I used a browser called Luakit for a while. It's a WebKit-based browser that has a user interface that's built with Lua and has a Vim-like default setup. It worked quite well but I changed back to a conventional browser when I couldn't get a proxy set up with good ad blocking, etc (luakit has no proxy or ad blocking, it relies on you installing polipo+privoxy or another http proxy setup).
So these days I use Chromium but I would love to get that minimal UI look and feel from luakit.
Anyway, I was never really worried about the things that you're worried about. xmms proves that anyone who wants to write a shitty, completely custom UI with shitty window decorations is perfectly capable of doing it already. In fact, the gtk+ client-side decorations branch didn't make it easier for someone to do that the way everyone seemed to think it did.
http://blog.martin-graesslin.com/blog/2010/05/why-you-should...
http://www.hadess.net/2010/05/client-side-windows-and-miscon...
It's different with something like android, that has something like a canonical organisation that can set interface standards. Vanilla linux has no entity with that much credibility.
With a well-specified server model (say using temporal logic), there should be no problem attaining pixel- and frame-perfect rendering.
Edit: if you want a hint at an actual solution, one need only send logical local timestamps along with each request, and introduce a timestamp handshake. The server very simply then need not swap in the backing store until it and the client have acknowledged that the logical timestamp should increment. Your convo then looks like this:
U - user / S - server / C - client
U->S: resize to 800x600
S->C: resize to 800x600, timestamp 12345
C->S: GL commands, timestamp 12345
C->S: more GL commands, timestamp 12345
C->S: more GL commands, timestamp 12345
C->S: OK, I'm done with timestamp 12345
S: render window decorations on C's backing buffer
S: push C's backing buffer from 12345 to the front
S->C: OK, it's now timestamp 12346
Also, I totally see how this is difficult (or maybe even impossible) in X, where the window manager is a separate client and there's no notion of inter-client synchronization. I haven't looked into Wayland enough to see what problems it presents (last time I checked it was in a state of major flux) but here's hoping its design entails a much simpler display model.