*> ... in this post I will argue against frequent soft forks with a single
or minimal*
*> set of features and instead argue for infrequent soft forks with batches*
*> of features.*

I think this type of development has been discussed in the past and has
been rejected.


from: Matt Corallo's post:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-January/017547.html










*Matt: Follow the will of the community, irrespective of individuals
orunreasoned objection, but without ever overruling any
reasonableobjection. Recent history also includes "objection" to soft forks
in theform of "this is bad because it doesn't fix a different problem I
wantfixed ASAP". I don't think anyone would argue this qualifies as
areasonable objection to a change, and we should be in a place, as
acommunity (never as developers or purely one group), to ignore
suchobjections and make forward progress in spite of them. We don't
makegood engineering decisions by "bundling" unrelated features together to*
*enable political football and compromise.*

*AJ: - improvements: changes might not make everyone better off, but we*




*   don't want changes to screw anyone over either -- pareto   improvements
in economics, "first, do no harm", etc. (if we get this   right, there's no
need to make compromises and bundle multiple   flawed proposals so that
everyone's an equal mix of happy and*
*   miserable)*


I think Matt and AJ's PoV is widely reflected in the community that
bundling changes leads to the inclusion of suboptimal features.

This also has strong precedent in other important technical bodies, e.g.
from https://datatracker.ietf.org/doc/html/rfc7282 On Consensus and Humming
in the IETF.

      Even worse is the "horse-trading" sort of compromise: "I object to
   your proposal for such-and-so reasons.  You object to my proposal for
   this-and-that reason.  Neither of us agree.  If you stop objecting to
   my proposal, I'll stop objecting to your proposal and we'll put them
   both in."  That again results in an "agreement" of sorts, but instead
   of just one outstanding unaddressed issue, this sort of compromise
     results in two, again ignoring them for the sake of expedience.

   These sorts of "capitulation" or "horse-trading" compromises have no
   place in consensus decision making.  In each case, a chair who looks
   for "agreement" might find it in these examples because it appears
   that people have "agreed".  But answering technical disagreements is
   what is needed to achieve consensus, sometimes even when the people

      who stated the disagreements no longer wish to discuss them.


If you would like to advocate bitcoin development run counter to that,
you should provide a much stronger refutation of these engineering
norms.