The main idea here seems to be a receipt bitfield. A bitfield to prevent double-spending of receipts was part of the plan in the original phase 2 proposal 2.
More recently, Implementing cross-shard transactions suggested using receipt nonces instead of a bitfield. The receipt nonce idea was also mentioned in the problem statement in solution #5 (#5 “removes the need for nontrivial amounts of state to store which receipts have been claimed and which have not; we just have a ‘next unclaimed receipt ID” ticker’”).
This seems to combine a receipt bitfield with solution #4 (“Enshrine one EE for ETH / asset holdings that everyone is required to understand”).
Was there an issue with using receipt nonces, or why did you go back to proposing a bitfield?
Nomenclature nitpick: “meta-execution environment” adds more confusion than clarity imo, I don’t see any way to distinguish it from the protocol (ditto for “enshrined EE”); e.g. everywhere it said “fee environment” I read “shard state” (as in, validator balances and EE balances are fields in the shard state). Maybe I see “enshrined meta-EE” as a fancy term for the protocol because I define EE’s as user-deployed wasm code (this definition of an EE versus the protocol is one way to arrive at an answer to “who can deploy EE’s?”).