BIP2, Section "BIP workflow" says this:

"The BIP editors will not unreasonably reject a BIP. Reasons for
rejecting BIPs include duplication of effort, disregard for formatting
rules, being too unfocused or too broad, being technically unsound, not
providing proper motivation or addressing backwards compatibility, or
not in keeping with the Bitcoin philosophy. For a BIP to be accepted it
must meet certain minimum criteria. It must be a clear and complete
description of the proposed enhancement. The enhancement must represent
a net improvement. The proposed implementation, if applicable, must be
solid and must not complicate the protocol unduly."

This is a lot of criteria for a simple editorial rule, hm? How could
any editor judge if an enhancement represents a net improvement without
opining on its merit? What's the Bitcoin philosophy?

Good point, this does seem to imply some value judgements. If we're open to making changes to what the criteria for a BIP are supposed to be, I think it ought to include:

• Formatting: contains necessary sections/headers, license, ...
• Editorial qualities: proper English, organized, ...
  
• Discussion: must have been presented on the ML or other common fora, received interest/discussion, ...
• Need for standardization: not every idea is worth publishing; if it isn't likely to affect multiple projects/pieces of software, it can just be software documentation instead.
• Scope: related to technology that supports the bitcoin currency.

By the way, Section "BIP Editor Responsibilities & Workflow" says this:

"For each new BIP that comes in an editor does the following:

- Read the BIP to check if it is ready: sound and complete. The ideas
must make technical sense, even if they don't seem likely to be
accepted.
- [...]"

Note how this is is (seemingly?) in conflict with the paragraph cited
further above. What is "acceptance"? Acceptance by the editor, by the
community (whoever that is), or by anyone else?

I don't see a problem here; my interpretation is that this is exactly about excluding certain value judgements from what the editor is supposed to do: they must judge soundness and completeness, without​ trying to guess whether the community is likely to accept the idea. "sound and complete" is perhaps too vague as a criterion, but I'm in support of explicitly excluding guessing of acceptance.

BIP2 has other problems (a lot of which date back to BIP1):

* It recommends licensing BIPs under BSD-2 or BSD-3, which are
software licenses. It's not even clear if they're applicable to

plain text. (The CC0 recommendation makes much more sense.)

No strong opinion about this, but that sounds reasonable.

* The Comments-URI thing is outdated and everyone seems to ignore it.

Comments-Summary is even weirder.

Agreed. It's unused, and sometimes misinterpreted. I think we should get rid of it.

* "Informational BIPs do not necessarily represent a Bitcoin community
consensus or recommendation". Aha, does this imply that Standards
Track BIPs need to represent a Bitcoin community consensus or

recommendation?

Indeed. I don't think BIPs should be representing community consensus or recommendations. But perhaps they can document individual pieces of evidence of acceptance; see further?

* Ever tried to write pseudocode or LaTeX in mediawiki format? It's

more than annoying, believe me.

I'd like permitting BIPs to be written in markdown.

Moreover, the entire "BIP status field" section is an attempt at
formalizing and describing the process of changing Bitcoin. That leads
to statements like these that specify when a BIP should be "Final"

* "A soft-fork BIP strictly requires a clear miner majority expressed
by blockchain voting (eg, using BIP 9)." That statement is highly
controversial. The point is that it simply doesn't belong in BIP2.
* "API/RPC and application layer BIPs must be implemented by at least
two independent and compatible software applications." same here
* Peer services BIPs should be observed to be adopted by at least 1%

of public listening nodes for one month.

Some forms of Status are useful I think, but they ought to reflect the author's intent, not the community's perception. E.g. "Draft", "Proposed", and "Withdrawn" make sense to me for any kind of standard. In Draft stage more substantial changes could be permitted, but would convey the idea isn't yet intended for adoption. Of course, the BIP1 status fields weren't really used, and the BIP2 status fields don't seem to be doing much better. If we assume that BIP3 status fields aren't going to be used either this is all for nought, but perhaps it's still worth trying with a significantly simplified assortment of statuses.

Things like "Active / Final" and "Rejected" relate to community acceptance, and I agree those don't belong in BIPs. Instead, could we perhaps have a field that indicates objective evidence of acceptance, such as listing which software projects have implemented/adopted it?

As far as judging consensus goes, perhaps actual consensus changes are an exception? I feel that for those, an "Accepted" status may actually make sense, because they actually require the ecosystem to have agreement about. But even then, it could be restricted to be an after-the-fact piece of evidence (whatever its activation rules are, they are met), rather than a judgement of community perception.

Regarding the "at least two independent and compatible software applications", I don't think this is a bad principle: good standards should be implementable by many, and having multiple implementations is an objective way of assessing that. I'm not sure that means being a requirement for its status, but at least an intent to have multiple implementations is a useful condition for the "Need for standardization" rule I suggest above.

The problems are similar to the Comments-Summary field whose purpose is
to represent a community judgment of the BIP. It can have these values:
* No comments yet.
* Unanimously Recommended for implementation
* Unanimously Discourage for implementation
* Mostly Recommended for implementation, with some Discouragement
* Mostly Discouraged for implementation, with some Recommendation

There's a reason why noone really uses this. Like the Status field, it
requires that someone (the editor? BIP2 doesn't specify this) makes a
judgement that looks somewhat authoritative, because it will end up in

the BIP header/metadata.

Agreed.

I think we should simply drop anything that requires an examination of
the meat of the BIP, e.g., the Status and Comments-* fields, and the
requirement to check the meat of a BIP. Instead, we should work on a
new process BIP that merely describes a simple process of publishing
BIPs, in which the editors focus on purely formal and editorial issues
(e.g., formatting, license, readability, filtering spam, ...). It's
great when they guide BIP authors by providing feedback on the
presentation of an idea, or even on the idea itself, but they shouldn't
be required to make decisions based on the technical or philosophical

merit of a BIP

I think my view is somewhat more restrictive than yours, e.g. that BIPs ought to satisfy some scope and need for standardization criteria, but I agree that as written in BIP2 today, Editors have too many judgement calls to make.