This is an ambitious project, Dan. I like it 
One of the motivations for the bag-of-coins treasury as opposed to the single-UTXO treasury is the inability of the latter to handle multiple donations within one block. On this note, you should know that transaction chaining is not currently supported, but is on the roadmap. Once it is implemented, you will be able to spend UTXOs that are produced by transactions that are not confirmed yet. However, with transaction chaining achieved, there will still be the problem that the initiator needs to be aware of the transaction that they are building on top of. So the motivation for the bag-of-coins treasury still holds in this world but the problem it avoids is slightly less acute.
By placing both scripts on the same UTXO, the Neptune consensus engine requires both the NPT conservation rules and the CCS identity rules to return True
Technically, these scripts don’t return true or false; they either halt gracefully, or else crash and burn.
I’m not sure I understand the solution to the chicken-and-egg problem. And I’m not sure the LLM does either 
Maybe you can get inspiration from the chicken-and-egg problem and its solution for SingleProofs. One of the ways to generate a SingleProof for a transaction is to Update it (bumping the timestamp or mutator set accumulator), and another way is to Merge two transactions that are supported by SingleProofs. In either case, the SingleProof program needs to invoke the Triton VM verifier to verify a particular claim, and that claim consists of a program hash, an input, and an output. That program hash must be the hash of the SingleProof program. How does the SingleProofprogram know its own hash? It cannot be hardcoded; or rather, hardcoding it requires first solving a hard problem related to Tip5 and preimage resistance.
Here’s how it is solved. Whenever any Triton VM program starts, its stack is not empty. It contains 16 elements. The bottom 5 elements of the stack agree with the hash of the program that is being run. The very fist thing the SingleProof program does is store this digest to memory for later use. Then later on when it needs to compile a Claimwith which to invoke the Triton VM verifier, the program hash field of that claim can be populated by reading the digest from memory.
“I will only validate this transaction if the Output UTXO carrying my identity ALSO carries a cleartext public announcement of its new state.”
Announcements used to be called public announcements but we dropped that adjective because they are always public. More importantly, announcements are tied to transactions, not to UTXOs.
- Balance: u64 (The visible NPT amount).
You probably want to use a u128 to store the number of nau; otherwise you are losing precision.
This [Janitorial sweeping] would be performed within neptune-core nodes operating in a composer role.
Have you considered the incentives for Composers? Because if it hurts their Composition time then are probably not going to do it.
it simply follows the “Search and Merge” instructions provided in the on-chain IBD Manifest.
Wait, what’s the IBD Manifest?