im reserving judgement on this one but first impression, this is a positive
one less "blockstreamer" in the maintainer group is always a positive. so we are now diluting the maintainer group away from one main "sponsor" more and more.
edit:
she seems to be "team chaincode/brinks" where her boss is J newberry. so lets see where that leads
(so not so diluted as first thought)
i will be looking into her meaning of when she says her interest is in the mempool acceptance code.. as that can lead into censorship of tx's before they can even get a chance to re-relayed to other nodes to be seen by the network/block templates. so for now reserving judgement and taking on the positives as they lay today.
she does seem to be swaying towards wanting fee bumps and high fee's and disregarding cheap fee tx's before they even get to mempool
https://www.youtube.com/watch?v=byUf8r61qc0she discusses things like wanting to have algo's to stop tx's with large signature segments that can delay validation at the mempool acceptance stage of tx relay.. (seems she is over complicating an easy fix)
the easiest solution.. by limiting txsigops and having a max 'in counter' of a tx.
thus not need all of her 'process and analyse then judge if acceptable' fluff
you dont need to process a tx and count the delay time by running it through time test scenarios and check time delay limit variables to judge things before putting into mempol/re-relay to other nodes.(which takes time in itself added onto the validation). instead you simply dont even start processing a tx with large 'in counter' or 'witness'(signatures)