I've been putting some design work into a minimalist browser like you describe, but starting from a different angle, namely starting with javascript as a first-class citizen, and a React-style virtual DOM as the rendering model. Javascript (or, I could be convinced, web assembly) is the primary interaction model with the browser, with HTML and CSS supported via polyfills.
The additional HTML5 suite of APIs would theoretically be supported by a plugin model, but given the depth of integration of some of the APIs, this might be a great deal more work than it sounds, and even more difficult to prevent the proliferation of questionable plugins to this backend. It would probably have to resemble something closer to the Linux distribution model; where an installed instance of the browser would come with a set of whitelisted plugins, with no real ability for the non-expert user to add plugins.
More important to me is the idea of making use of client certificates to attest identity more strongly, together with masking the use of those certificates over third-party channels. So if I went to facebook.com I would present a cert "abcd" (a self-signed certificate), and if I went to yelp.com I would present "bcde". If yelp loaded content from facebook.com, I would present "cdef". Similarly for cookie handling, at least initially.
My hope would be that websites would associate multiple client certs with a given "user" on their site, but unless the user explicitly associates a cert with an identity there's no way (outside of fingerprinting, etc.) to make that association; all third-party interactions show as incognito sessions. Eventually the goal would be that (if this technique is widely adopted) that cookies become kind of useless in favor of strongly attested server-side identity (rather than using bearer tokens in the form of cookies) that can be associated with session data.