The idea sounds interesting and it should work without problems with Lightning, as far as I know. The only thing I don't know if a full private key (T) wouldn't be too long enough to work as a secret for LN implementations.

I was however wondering why R is necessary. It doesn't allow the guarantor to run away with the money because he doesn't know T_B. But the problem that the coin/voucher could lose value if the guarantor doesn't exist anymore and fails to publish it is pretty severe in my opinion.

So what I would do instead: The voucher provides access to a simple funded Lightning channel - that would mean, that instead of using T and R for the multisig transaction, one would use T_A and T_B. The guarantor, in this case, wouldn't have to interfere anymore once he sold the coin - if the buyer wants to redeem the coins with an offchain transaction, or the guarantor goes offline (and thus, cannot receive and route LN payments from the buyer), he simply closes the LN channel as he has access to both keys once he reads T_A destroying the hologram.

Maybe I overlooked something important, however.

Edit: I think I definitively overlooked something: the problem with the setup I proposed here is that the LN channel in this case wouldn't really have a "counterparty" as both keys can be controlled by the buyer once he opens the hologram. So there is no connection to the rest of LN because the guarantor doesn't control any key exclusively, and thus would never allow payments leaving the channel, because the buyer could "refill" it itself.

So unfortunately it seems R is necessary, and thus we would have a "miminal trust" solution.