In order for the sanitizer API to be usable, the browsers need to use the lower-level primitives anyway (e.g. they have to have a concrete whitelist, they need an inert DOM). It might be just a matter of exposing those primitives as a web API - which I believe might be simpler to agree on, than e.g. a list of necessary customization options and hooks for the sanitizer, and their actual implementation.
For example, for clients to migrate to a native sanitizer, the native impl. needs to provide a superset of customization options for all large userland sanitizers (in other words, SAFE_FOR_JQUERY, name policies, URL policies and all other features must be possible to implement via the exposed native hooks). A missing configuration knob would mean that a DOMPurify-ng (backwards compatible & wrapping over the native sanitizer) would have to make a second pass, legacy sanitization.
I’m just wondering if this wouldn’t be actually simpler to agree on & implement the primitives that don’t require that many config knobs to be functional (and so far over the years the client side sanitizers kept adding more config settings, suggesting that the devs actually need them). Lots of those primitives are already there and just need some finishing touches (e.g. the elem/attr list is implemented in browsers due to existing sanitizers, inert DOM APIs exists, but is inconsistent, DOMParser exists etc.). This task might be simply less bikesheddy, and more tangible to implement, than a full sanitizer.