I do wonder how it could ensure the code running is the actual code signed for as its hash would be different though.
At signing time, the signer reveals a hash for every non-taken branch, so that the commitment still checks that leaf being executed was an admissible one.
The dead-code elimination goes further than that, because at the top level this hash root is hidden inside a public key which can be a key controlled by all the participants jointly (or some subset if appropriate). At signing time if these top level parties are available and cooperate they can just sign, and no script is ever revealed, it's impossible for third parties to tell it was ever there-- saving resources and preserving privacy.
(And the possibility to complete the transaction using the script means they don't gain from failing to cooperate)
Parent talks about the „Lightning Network“
So is the "BMW and its suppliers" network I imagined. But this network is simpler and more customized to the needs of this particular use case.
Of course using the LN would be a viable alternative to a custom solution.
Roughly speaking the Lightning Network works similar to a „current account“ that businesses have between each other but does not require the actors to trust each other. The parties initiate a transaction by each one sending Bitcoin to a public multi signature address. The resulting transaction cannot be spent by any one alone. Now, this unspent transaction serves as an initial balance and opens a channel between the parties on the layer 2 network. Bitcoin may now be wired back and forth between the parties on layer 2 w/o needed to be settled individually on the Bitcoin block chain. Finally, if all parties agree by signing a second, settling transaction the resulting balance is written back to the Blockchain to whatever address the participants initially agreed upon. Theoretically, there could have been billions of Bitcoin transactions over the years on the Lightning Network which would be eventually represented by only two transactions on the chain.
Now, taproot improves this scheme by introducing Schnorr signatures. Up to now every member of the multisig transaction I just talked about needed to contain the public keys of all parties which in turn needed to be verified against all their private keys. Since transactions are limited in their size, this limited the applicability of multisig transactions. Now, Schnorr signatures allow for aggregation of public keys so the transaction only needs to contain a single number instead of hundreds or thousands. Of course, this also speeds up validations of transactions.
I hope this all made sense. I have yet to see practical applications of a Lightning Network „scheme“ but I heard El Salvador is using it for cheap Bitcoin transactions (although not applying Schnorr signatures yet).