Red blocks are “the orphans of DAG”, they are blocks that arrived too late and therefore their POW is not counted as contributing to the weight of their respective branches. This is formally defined by the PHANTOM/GHOSTDAG procedure. I propose to include their txns in the UTXO set as well.
The motivation is that it allows for very fast 1 confirmation: In many use cases there is no real threat of a double spend, and the user only wants to know that her txn entered the ledger and is accepted for sure (assuming no double spend). This gives protection, e.g., against temporary 51% attacks, where an attacker gets hold of a majority of the hashrate for some limited time, and is able to gain full control over the set of blue blocks and to reject all txns included by the honest miners and users, which are now inside red blocks. (A counterargument is that valid txns that were rejected by this temp attack will be reintroduced to the mempool and mined again, post the attack. I still argue that this proposal greatly simplifies the UX for users/integration points, and that counting on the mempool process adds risks and uncertainty - mempool may bloat due to the attack, fees can temporarily skyrocket, etc.)
This can be achieved by simply iterating over txns in the set of blocks B.past \setminus B.selectedParent.past according to some deterministic topological ordering, and for each txn adding it to the UTXO set if it is consistent with the current UTXO.
From a DAST point of view, there is no need to keep in memory the information on red blocks, it can be simply part of the UTXO handling around the accepting (blue) block.
Note that txn fees should not be paid to the miner of red blocks. Note further that even red blocks must respect the mass and gas caps, and can’t introduce more txns than allowed.