Accurate description. Yet there are two claims that just contradict each other and cannot be squared:

1) consensus and (mempool) policy are truly separated.

If so, then the latter is up to each client implementation - or rather each individual node config.

If we believe that ( I do, and based on your comment so do you ) then we *must* accept node runners' autonomy over their mempool. Even if it means that it will no longer reflect the perfect world for dependent layers/system (e.g. lightning)

2) there is an objectively "optimal" mempool (the one that 99.99% approximates of what will be mined by miners) that should be adhered to by all nodes.

If that is the case, then the policy settings of the 95%-dominant client are *effectively* like consensus. And should be subject to the same level of scrutiny as a consensus changing soft fork.

What bothers me in the current discussion is that Core try to have *both ways*. They (Lopp being the most vocal) claim it "just a policy setting", i.e. #1, where plebs dont get a say since it is Bitcoin Core dev business. And at the same time claim that we have to have a "common mempool" (i.e. #2), too, because otherwise it would be detrimental to the overall network

So which one is it???

If The Mempool™️ is a common (#2), then you must allow broad discussion. And you should really make it part of protocol consensus.

Otherwise let people run their own settings and leave them be.

tl;dr You can't have your cake and eat it too.

----

Detour:

What really happened imho is that Core and layer2 devs have always banked on the implicit assumption that mempools are virtually identical among nodes - because they all ran the same software, with the same default settings.

They are now caught with their pants down, as this was always a lazy assumption (one I would have made too!! not prentending to be smart here), and are trying to force the reality fit the model.