I discovered a race condition in sendrawtransaction. For details: see my comment in https://github.com/bitcoin/bitcoin/commit/1d46fe3327f6645fd79b442cd72ef422418c1a50.

If you send a raw transaction which has already been broadcasted, then you don't know whether you'll receive an RPC_TRANSACTION_ALREADY_IN_CHAIN exception, since you don't know whether a new block has just been received, which includes the transaction. There are use cases where such RPC_TRANSACTION_ALREADY_IN_CHAIN occurrences do not indicate an error; however, since this type of occurrence is very rare, developers are not likely to be aware of the possibility, and silence the exception. As a result, applications can potentially experience hard-to-diagnose, very rare errors.

I think the core of the problem is that sendrawtransaction tries to combine two use cases:
A: publish a transaction on the Bitcoin network
B: re-transmit an already known transaction to peers
RPC_TRANSACTION_ALREADY_IN_CHAIN might make sense for B, but for A (which is, IMHO, the primary use case) it is confusing.

result_0.pushKV("allowed", false);
        result_0.pushKV("reject-reason", "max-fee-exceeded");
        result.push_back(std::move(result_0));
        return result;
    }
    result_0.pushKV("allowed", test_accept_res);
    
    
    if (test_accept_res) {
        result_0.pushKV("vsize", virtual_size);
        UniValue fees(UniValue::VOBJ);
        fees.pushKV("base", ValueFromAmount(fee));
        result_0.pushKV("fees", fees);
    } else {
        if (state.IsInvalid()) {
            if (state.GetResult() == TxValidationResult::TX_MISSING_INPUTS) {
                result_0.pushKV("reject-reason", "missing-inputs");
            } else {
                result_0.pushKV("reject-reason", strprintf("%s", state.GetRejectReason()));
            }
        } else {
            result_0.pushKV("reject-reason", state.GetRejectReason());
        }
    }
    result.push_back(std::move(result_0));
    return result;
},
    };
}
static RPCHelpMan decodepsbt()