> there are already ML-KEM-only implementations in various libraries, so if we want interoperability then it's best to have a standard document

“People are already doing it, so we might as well rubber-stamp it even if it’s not great” introduces problems of its own: people will perceive that rubber-stamping as validating it, and now they’ll use it even more, where perhaps if you held back, they wouldn’t.

(There are counter-arguments as well, of course. A couple of relevant cases that spring to mind where a body has not aligned with usage or expectations: W3C lost control of HTML, and it was probably for the best, but they remain a relevant body in closely-related areas; and OSI licence approval is a horribly broken political process which is almost universally misunderstood and close to frozen in time, yet they haven’t suffered like they should have for their misdeeds, they pretty much got away with it. There was also that thing somewhat recently about FedRAMP rubber-stamping Microsoft Cloud despite it failing dismally, because US government agencies had already started using it too much; and I wonder what that does to their credibility.)

This is also a concern with informational/independent submissions through IETF. They are frequently perceived as having IETF/standards weight.

If it's supported it will be used, e.g. by vendors which decide for some reason to use it

Null encryption used to be supported as well, and no one was forced to use it.

But when something insecure is supported by a protocol it will lead to security hiccups.

If it's dangerous it shouldn't be supported.