James,
Unfortunately, there are technical reasons for sponsors to not be monotone. Mostly that it requires the maintenance of an additional permanent TX-Index, making Bitcoin's state grow at a much worse rate. Instead, you could introduce a time-bound for inclusion, e.g. 100 blocks. However, this time-bounded version has the issue that Roconnor raised which is that validity "stops" after a certain time, hurting reorganization.
However, If you wanted to map this conceptually onto existing tx indexes, you could have an output with exactly the script `<100 blocks> OP_CSV` and then allow sponsor references to be pruned after that output is "garbage collected" by pruning it out of a block. This would be a way that sponsorship would be opt-in (must have the flag output) and then sponsors observations of txid existence would be only guaranteed to work for 100 blocks after which it could be garbage collected by a miner.
It's not a huge leap to say that this behavior should be made entirely "virtual", as you are essentially arguing that there exists a transaction graph we could construct that would be equivalent to the graph were we to actually have such an output / spends relationship. Since the property we care about is about all graphs, that a specific one could exist that has the same dependency / invalidity relationships during a reorg is important for the theory of bitcoin transaction execution.
So it really isn't clear to me that we're hurting the transaction graph properties that severely with changes in this family. It's also not clear to me that having a TXINDEX is a huge issue given that making a dust-out per tx would have the same impact (and people might do it if it's functionally useful, so just making it default behavior would at least help us optimize it to be done through e.g. a separate witness space/utreexo-y thing).
Another consideration is to make the outputs from sponsor txn subject to a 100 block cool-off period. E.g., so even if you have your inverse timelock, adding a constraint that all outputs then have something similar to fCoinbase set on them (for spending timelocks only) would mean that little reorgs could not disturb the tx graph, although this poses a UX challenge for wallets that aim to bump often (e.g., 1 bump per block would mean you need to maintain 100 outputs).
Lastly, it's pretty clear from a UX perspective that I should not want to pay miners who did *not* mine my transactions! Therefore, it would be natural to see if you pay a high enough fee that users might want to cancel their (now very desirable) stale fee bumps by replacing it with something more useful to them. So allowing sponsors to be in subsequent blocks might make it rational for users to do more transactions, which increases the costs of such an approach.
All things considered, I favor the simple version of just having sponsors only valid for the block their target is co-resident in.
Jeremy