“ It is possible to configure your node to to run in pruned mode in order to reduce storage requirements. This can reduce the disk usage from over 350GB to around 7GB.”
The pruned/archival distinction is orthogonal from the full/simplified categorization. A full node that pruned spent transactions is not a contradiction of terms.
Edit: a “full” node is one which fully validates blocks, meaning it checks that blocks meet all of bitcoin’s consensus rules. All data in bitcoin is either validated once the first time it is seen (like witness data), or at most twice (an output and its later spend). Pruned nodes garbage collect this data once it can provably never be referenced again. This does not diminish the nodes ability to check bitcoin’s consensus rules, so it is still a full node.
Full node is an abbreviation of "Fully validating node", which was a term created in contrast to "simplified payment validation" (which basically means perform no validation yourself and trust that the majority of hashpower is being honest due to pressure of other participants validating).
Archive node implies non-pruned and txindex enabled?
One thing that made me laugh regarding the Ethereum “archival node” semantics debate was that equivalent functionality (immediate lookup of any transaction by address) in Bitcoin requires an additional index, like ElectrumX. Apparently many of the loudest Bitcoiners would benefit from understanding the distinction between a block explorer and a full node.
It is definitely possible to run a lightning node using a pruned backend. The official implementation doesn't "support" it, but that is only because some additional thinking is required on the end user's part. It is really just a matter of implementing the code to instruct the backend to get the pruned, but still needed by lnd, transactions - and the work is happening:
From [1] in the parent.