I generally like the direction it's moving towards. I appreciate you sending it my way as well for my feedback since I think we do see things differently, but there's still a mutual vision we see to steward the development of the community.

With that in mind, I think it's worth calling out that 3 of the 4 things editors don't do which I think are fundamentally missing from the process which is causing lots of controversy. I may be misaligned with the value that the editors see for themselves, but I call this out with the intent to say effectively, "If it's not the editors taking on these responsibilities within the community than who's responsibilites are they?".

More specifically, here's the critiques I'd put forward for this:

1. Decide Winners:

This is fundamentally disaligned with the concept of consensus. Framing this as deciding winners/losers is built on an assumption that once something is a standard it's the only way to do something which is never the case. Standards are meant to determine common building blocks that can be adapted to the needs of implementers and get people fundamentally aligned so that they only need to focus on the minor interoperability details.

The governance model of fork and compete is the fundamental default of the world. By the very nature of human agency we always have the option to opt-out. In my mind, the purpose of EIPs is to provide more value than the fundamental default. Put another way, their meant to be a forum for us to organize ourselves chaordically at the human layer in a naturally chaotic world so that we can be more technically aligned and ultimately save time.

For this I believe we need to reframe it less about deciding winners and more about deciding what we as a community (at least those who choose to participate in the process - there will be people like uniswap who opt out) collectively endorse. Furthermore, I think it's important to define mechanisms for how this endorsement is achieved. Intentional obstructionism by way of vetocracy incites frustration at the very basis of people who want to build and make progress. We need an outlet to be able to reach a conclusion even if it's not something we agree with.

2. Manage:

Simply put, this is an extension of whoever remains the maintainer of the repository where this information is archived and published. Right now this is the EIP repository. If we move it to a different repository then at that point the new repository would be given the legitimacy that's bestowed with being the canonical play to archive and publish this information. This legitimization has been built up because the EIP process and EIP repo is known as the canonical place to put this information in the Ethereum ecosystem.

If we move it then we also move that legitimacy. The same thing occurred when WHATWG decided to move the HTML standard out of W3C because they wanted the document to be a living standard. This ultimately creates a bit of confusion to majority of people who don't wish to be engaged in the nitty gritty details of moving standards forward and just have to rely upon them for other reasons. So, since this information needs to be published in order to coordinate implementers of the Ethereum protocol if it gets moved to the AllCoreDevs forum. If it's recognized that these are independent of the EIP process than that effectively moves the EIP's legitimacy to the AllCoreDev forum.

There is a way that we can cohesively maintain the legitimacy within the EIP process as the go to place for anything standards related while still deferring that power to AllCoreDevs. Effectively the way we do this is by establishing that AllCoreDevs will be governed by the EIP process (and therefore the EIP process actually becomes a governance process, facilitator, and tools maintainer for speciality rings), but they will maintain their own methods of publishing and archiving material related to their authority. This has the effect of keeping the EIP process legitimized while also getting out of the way of the core devs and allow them to maintain their own separate repository. By doing this we solidfy the EIP process as the best place for the ethereum community to facilitate discussions, produce standards, and coordinate ourselves to improve the technology.

This argument is largely the same for the "assert correctness" principle as well. While the EIP process doesn't necessary assert the correctness, it can assert that it's the place for experts to congregate and collaborate to make this assertion. Remember, just because the assertion is made doesn't make it true.

3. Track Registries

Let's look at this a bit more generically. A registry is just a place to coordinate people in a centralized way. This is useful to reduce conflict or at least establish a way to resolve conflict when it arises. 99% of the time technical decisions don't matter enough to promote conflict and so they fly under the radar. For the 1% of time where the conflict does arise it's still useful to have a way to have a record of who's landed where and understand why they've taken the positions they have. Even if it means that no consensus was achieved.

So, while I think it's fine to ignore registries (for now SDO's are naturally reliant on them) it's important to recognize that if it's not done by EIPs then it's gotta be done somewhere else. Personally, I think this is a good use case for a separate DApp rather than Github, but I've never sat down to try and actually build something like this.

So overall, I think I'm fundamentally disaligned on what the purpose of the EIP process is which is why I've been so adamant on adapting it to these new view points rather than starting a separate place. I recognize it's extremely hard to build the legitimacy that the EIP process has already established. With that said, it's quite clear what the EIP process is today and what the community needs now is disaligned hence the outcry we're seeing from the AllCoreDevs. I think if other parts of the community were more coordinated (e.g. wallets/ERCs) we'd be seeing something similar from them too and that's why I'm opting to stay engaged and trying to change the process rather than to fork and separate.

Hopefully, that provides some feedback (a lot more than I originally planned) for you to chew on for a bit.