I understand that SegWit is backward compatible (soft-fork) from this perspective.
So, for old nodes the following output script (scriptPubKey)
OP_n (where n from 0 to 16) <2-40 bytes>
... is considered as anyone-can-spend and in "concatenation" with the empty input script (scriptSig) it will be always valid.
For new (updated) nodes it will be considered as SegWit, so the special SegWit validation process, as Pieter Wuille described, will start.
Observing only this, everything is clear to me.
What is not clear to me is how all this will work when the structure of the transaction has been changed from SegWit.
Namely, according to bip144, the structure of the transaction has been changed by "expanding" the transaction with two bytes (marker (0x00) and flag (0x01)) after
version field, and also adding witness data after
tx_outs and before
For new (updated) nodes this is considered as a sign that there is
witness data, however, for old nodes this is a transaction with 0 inputs and 1 output which is considered invalid so they will always discard this transaction (especially since there is also
witness data that is not clear to them at all).
Even if we would consider that the old nodes would not relay these transactions to other peers, they would not even accept them in the blocks they receive from the miners, because for them these are completely invalid transactions (valid from the first perspective of inputs and outpus since they are anyone-can-spend, but invalid from this second, structure perspective).
Can someone explain to me how this works? I misunderstood something.