I'm really not shifting the goalposts at all. The purpose of a spec is that an implementation can be built on it, and any spec worth its salt should be verified

I'm really not shifting the goalposts at all. The purpose of a spec is that an implementation can be built on it, and any spec worth its salt should be verified for clarity, feasibility, soundness, etc. by implementations. In fact, W3C had a requirement for two independent implementations for any spec to reach recommendation status. So in this context, a fork can't be meaningfully counted as independent implementation; if it were, I could create an empty fork on github and call it a day to satisfy the requirement of two independent implementations. By forking, you inherit a code and test base encoding all quirks and warts (= that which is actually spec-worthy), but don't gain any insight into the spec quality or alignment with a spec at all. Now, of course, we have a much worse problem with web specs: that no browser has been started from scratch since basically forever. Thus, the spec can serve merely as an after-the-fact documentation of existing browser behaviors, or at best record an intent for "browser vendors" to implement some feature. Which is what WHATWG basically is and how it came to be: a platform for "browser vendors" to agree on evolving web standards without the ceremony of a full-blown spec process like W3C's. There's nothing wrong with that; it's just not what should be called "a standard", especially if it doesn't produce a published, versioned document or other deliverable but is always work-in-progress by design.