I would argue that the web browser evolved, by accident, into the closest thing we have to a portable and usable desktop OS.

However, to me the browser is more like a "requirement statement", than a solution.

The success of the web is just a symptom that:

- users want applications that work on computers. Win vs Mac vs Linux vs Mobile vs ... is all nice and well for us geeks, but to real-world people, it's just a frigging computer.

For some reason, OS vendors were never able to agree on anything substantial, but browser vendors did.

We need a W3C for OSes. (Except, maybe one with a constitution, a parliament, a police force and a tax enforcement agency.) They have to decide an OS-level API.

They will probably fight over which programming language to use to write applications, but whatever they decide, someone will write a brainfuck compiler frontend for it, anyway, and it will not matter.

- users want to use applications, not spend hours installing them.

The browser got that right by accident, by using reflection and stringly-typing ; you 'install an application' by 'sharing a bit line of text that you can copy paste in an email', and you 'find an application' by typing a name in Google.

The browser stopped short of getting anything else right about application, feverishly waiting for someone to solve "librairies" for them by just downloading 100 versions of jquery and praying.

The OSes of the future will need interoperable, discoverable, namespaced apps, with namespaced, signed, shared libraries.

- users want applications with GUIs. And pretty much all applications will want to display the same basic suff that has been known since Smalltalk. (And the users don't really give a damn that the Facebook buttons do not look exactly the same as the Twitter buttons.)

The OSes of the future will need a standard way to draw the Smalltalk-level UIs.
And easily make the same application with a different logo on it, because the customer wanted Facebook, but more yellow.

- also, users wants games that just take all the screen and they could not give a damn about the buttons in the game, they want to play. And it should be fast.

The OSes of the future will need a standard way to use GPUs.
And, really, nothing else. The game devs don't really want an OS, actually. Ask Casey Muratori. Let the game devs do whatever they want with the computer, they know better than you, and will write semi-portable machine code (aka C) anyway. Your "browser" thingy would makes them laugh hard if they had the time to laugh while peeing in a jar to finish their next version of CoD.

- and users have a computer to do things with other people, so of course networking. What do you mean there are computers without networking ?

The OSes of the future will need networking. But since the people who designed ethernet and Internet and TCP/IP and routers etc... were border-line geniuses with infinite vision (apparently they were high on LSD most of the time), people will just use TCP/IP to communicate with our cousins of Mars.
But we'll have to come up with something better HTTP. And JSON.

And if we could let the OS handle network identity management ? So that all applications don't have to speed the first six months of development on the "login" page ?
Yes I know it's hard, but it's harder when it's not the right part of the computer doing it.

- and some, a tiny little portion of some users want to use computers to read the news. So, yeah, of course the OS would have shareable document reader. And those documents might very well be HTML (although, we all know that we need better.)
And the New York Times would build a "smalltalk-like app" to organise columns and images and typography and whatnot on an infinite canvas, and sometimes, display the text of an Op-ed - rather than turning the text of an Op-Ed into a weird tree of DOM elements, and have a poor soul come up with 1000 lines of CSS that do the work of 10 lines of code.

Of course it will not happen, but it was nice to imagine that.