I share your concerns, especially with regard to the existing standard library which could rapidly become a cluttered and inconsistent mess.
Would it still work if #15 were dropped and/or if correctness were extended to include adhering to a design goal document? That is, if a design goal of a module is to provide the minimal functionality that gives expressive power, you might very well say that adding a collectNot method, while somewhat convenient, is not correct by virtue of missing the design goal (in addition to being something of a misuse of PartialFunction).
For brand new projects this wouldn’t work, but I think the idea is that things that go in should be reasonably mature. It ought not be too much to ask to have a short document describing the philosophy behind the module, against which technically correct but design-incorrect patches can be measured.
As an example, the design document for the existing Scala collections would state that methods should appear as high in the hierarchy as they reasonably make sense so that, for instance, a patch implementing sliceUntil[A](Int, p: A => Boolean) on Vector alone would be rejected.