Please read this, thinking that there may be such a possibility.
I fork each version of Bitcoin to make Fujicoin. I am currently testing Fujicoin made from v22.0rc2.
https://github.com/fujicoin/fujicoin

I often create large transactions with more than 350 inputs, but in v22.0, I fail to transfer money due to lack of fee about once every few times and get into a "not in memory pool" state.
This phenomenon sometimes occurred in previous versions. It rarely occurred in v0.21.x, but it seems that the frequency increased in v22.0.

Specific explanation
--------------------

The following image is the dialog at the time of remittance.
![fujicoin5](https://user-images.githubusercontent.com/7656623/128798045-08037fc5-d4ea-4dd2-9a5d-813cbd33c14a.png)

The following images show the remittance result and its details.
![fujicoin6](https://user-images.githubusercontent.com/7656623/128798270-287f9586-4a31-449d-9e69-853a6a5c3b4b.png)

![fujicoin7](https://user-images.githubusercontent.com/7656623/128798285-dc45a05e-0d71-488a-8e03-a46d30de7bdc.png)

I made a program with python and calculated fee from raw Tx. In my calculation the fee was 2.57729334.
Therefore, it is correct to be out of memoly pool due to insufficient remittance fee.
In this case, the pre-remittance fee calculation is incorrect.

As you can see from the figure, this phenomenon can be reproduced many times if the wallet state is the same.
Unfortunately, I don't have any more parsing ability, so I can't identify what kind of transaction causes a calculation error.

Fortunately, I've never experienced this with regular size transactions. Transactions that could not be remitted can be canceled, so there is no actual harm. 

I think it's pretty difficult to identify this problem, but I think it's very good if it improves.

* The search continues to search for better solutions after one solution has been found. The best
 * solution is chosen by minimizing the waste metric. The waste metric is defined as the cost to
 * spend the current inputs at the given fee rate minus the long term expected cost to spend the
 * inputs, plus the amount the selection exceeds the spending target:
 *
 * waste = selectionTotal - target + inputs × (currentFeeRate - longTermFeeRate)
 *
 * The algorithm uses two additional optimizations. A lookahead keeps track of the total value of
 * the unexplored UTXOs. A subtree is not explored if the lookahead indicates that the target range
 * cannot be reached. Further, it is unnecessary to test equivalent combinations. This allows us
 * to skip testing the inclusion of UTXOs that match the effective value and waste of an omitted
 * predecessor.
 *
 * The Branch and Bound algorithm is described in detail in Murch's Master Thesis:
 * https://murch.one/wp-content/uploads/2016/11/erhardt2016coinselection.pdf
 *
 * @param const std::vector<CInputCoin>& utxo_pool The set of UTXOs that we are choosing from.
 *        These UTXOs will be sorted in descending order by effective value and the CInputCoins'
 *        values are their effective values.
 * @param const CAmount& selection_target This is the value that we want to select. It is the lower
 *        bound of the range.
 * @param const CAmount& cost_of_change This is the cost of creating and spending a change output.
 *        This plus selection_target is the upper bound of the range.
 * @param std::set<CInputCoin>& out_set -> This is an output parameter for the set of CInputCoins
 *        that have been selected.
 * @param CAmount& value_ret -> This is an output parameter for the total value of the CInputCoins
 *        that were selected.
 */
static const size_t TOTAL_TRIES = 100000;
bool SelectCoinsBnB(std::vector<OutputGroup>& utxo_pool, const CAmount& selection_target, const CAmount& cost_of_change, std::set<CInputCoin>& out_set, CAmount& value_ret)