bitcoin core – Sigop count and its influence on transaction selection

This question was inspired by this recent mempool phenomenon: some transactions were left out from blocks even when they had a competitive fee-rate simply because they had a positive sigop count and the max sigop count was reached before the block template was totally filled. Whatever empty space remained was filled using zero sigop txs.

It seems that miners have to solve a knapsack-like problem where they are constrained by two hard limits: one is the size of the block and the other is the maximum amount of sigops. The former is the one actually optimized for in the standard mining algorithm, and the latter is more-or-less considered due to the content of this PR, which penalizes the size of a transaction if it has a high sigop count.

Q1: Suppose the mempool contained no zero sigop transactions and that
the selection algorithm constructed a block template consisting of
high sigop count transactions only but lots of available space. Is it
guaranteed by the choice of nBytesPerSigOp that this block template
is more convenient for miners that one where the block is full and
high sigop transactions are avoided?

Judging by this answer it’d seem as if indeed the miner could earn slightly more if they did some clever work, but that it’d be hard for it to actually happen in practice.

Q2: Why isn’t the standard mempool-based fee estimation algorithm
sigop-aware? In a context in which there are lots of high sigop
transactions with competitive fee-rates, there are two different next
block fees depending on whether the transaction one is about to craft
has a positive sigop count or not.