the interface is not so hard, browser needs to communicate via lines of text to one process. for that it has stdin/out. process that starts the browser can arrange those fds internally as is needed. doing that for multiple processes is what i called demuxing.
it doesn't need to be a 9p file server, it's too trivial for the features presented so far. though it could also be a fifo or file on disk. doesn't matter at all. when a user middle clicks a link pointing to URL the browser should write: "new URL" -> depending on URL open new browser process with that url as argument -> or open something else, for example mpv when a user clicks a link normally: "change URL" -> same as above -> if there's no special rule send it back to browser: "change URL". only then the browser should go there. current browsers assume the browser *also* has history state. thus the history selection gui will be provided by browser and we have to replicate this in some ugly way, unless somebody isn't too lazy to change that. when a user presses the #th entry in history list: "goto history #" -> if it's a youtube or some shit like that, then handle it in mpv. otherwise write it back to the browser. it doesn't need to scale, the amount of information passed around here is trivially small. you can even write everything directly to disk like opera does it for me right now. there's even more to learn from webfs. it does so many things that a designated file server starts making a lot of sense. It even includes cookie and SSL handling. For the future, being at that layer it seems easy to extend, so that stupid crap could be filtered out of horrible web sites (the kind of shit mentioned here for example http://idlewords.com/talks/website_obesity.htm) more easily with simple shell scripts. Though webfs currently doesn't save the history or keeps state of currently open windows in the way i described earlier.
