If you step back a little what we have today is a combination of a common browser implementations (aka. the DOM tree + render logic) and bunch of standardized parsing and interpretation logic that maps textual versions of CSS and HTML to this.
For better or for worse, this stuff is standardized via WhatWG & W3C as well as the three remaining browser engines (chromium, gecko, and safari) whose intersection of behavior is the de-facto reference and also what is driving standardization forward. Forking those definitely does not make sense unless you are the size of Apple or Google and more than one big company has backed out of pushing their own implementation (e.g. MS).
Most so-called full stack apps bypass the business of parsing of html5 & css in favor of just directly driving the DOM api. This provides greater flexibility and generally sidesteps a lot of complexity, bugs, etc. related to subtle differences between the 3 implementations. A typical index.html contains little more than the bare essentials to load the javascript; which then drives the DOM directly. This annoys some purists/traditionalists on the web definitely not in a position to fork or support their fork of any browser but makes little difference to search engines, users, or browser implementations.
So now having established that this is mostly an academic discussion of forking something that is highly unlikely to be ever actually forked (successfully), we can look at the underlying question.
This would be whether the DOM still an appropriate way to represent highly complex and dynamic applications that are not primarily documents and increasingly cover the whole range of any kind of interactive application possible (terminal UIs, windows based UIs, games, VR/AR, voice driven chat bots, etc.). For better or worse, most web development is about providing an illusion of more interactivity than a typical document would provide. The business of rendering static text to a browser is kind of a solved problem. It's everything else that's kind of hard to deal with via a DOM api. WASM is breaking this discussion wide open as suddenly people are porting decades worth of native code to run in a browser. Just because you can doesn't mean you should of course. But there's a lot of UI that can run in a browser that doesn't need or completely bypasses the DOM these days. Accessibility is a good remaining reason to still use it. But beyond that?