Mitigating a Double Spend Attack by Punishing the Attacker? One of the main reasons it's not safe to accept Bitcoin with 0 confirmations is due to the possibility of a double spend (where Mr. Scammer first sends 1 BTC to Alice and then creates an identical transaction in which he sends the same 1 BTC to Bob or to another address controlled by himself. If the network ends up including the second transaction in the blockchain only Bob (or Mr. Scammer himself) will be viewed as the rightful owner of the coins and Alice will be left with nothing).
However, being that it is impossible to hide a double spend forever, and everyone on the network will eventually discover that Mr. Scammer double spent his coins, why is it not possible to penalize the double spender in order to reduce the economical incentives of doing so in the first place? For example, we could create a special type of transaction in which Mr. Scammer has to lock up an equivalent amount of BTC for a specified amount of time. If the network indeed concludes that a double spend has occurred we &quot;burn&quot; (or destroy) the locked up BTC.
Wouldn't this significantly reduce the likelihood of a double spend occurring in the first place?
Given two transactions that spend the same input, there is no way to know which one 'came first' or is the 'rightful' transaction. Because of this, it is very difficult to enforce a 'no double spend' policy in this way. How can you guarantee that you have the transactions ordered correctly? What happens if some nodes on the network see the transactions arrive in a different order? Or what if a scammer sends a payment, but then claims that a transaction that pays those same coins back to themselves is actually the 'first' transaction? Etc.
This is why the blockchain exists in the first place: to give an explicit order to the transactions which occur on the network. Attempts to make 'zero-confirmation transactions' as reliable as confirmed transactions will never succeed, and if they could, then we could just do away with the whole blockchain! Perhaps there are ways to make double-spend attempts less likely to be successful, but ultimately if you are accepting zero-confirmation transactions, then you are incurring some risk of being double spent against.

For example, we could create a special type of transaction in which Mr. Scammer has to lock up an equivalent amount of BTC for a specified amount of time. If the network indeed concludes that a double spend has occurred we &quot;burn&quot; (or destroy) the locked up BTC.

You have more or less described an escrow system, in which a third party is employed to ensure that the transaction in question proceed smoothly. This is possible today, and indeed some markets provide access to this sort of protocol.
Keep in mind: if you are requiring that the user lock up some coins on-chain as collateral... that will require a bitcoin transaction to create this 'locked up UTXO'. To create that UTXO you will have to wait for an on-chain transaction to confirm... and at that point you might as well just wait for the payment to confirm in the first place! If you don't wait for it to confirm then you're just back at square one in regards to double-spend risk.
Attempting to automate this doesn't seem viable, for reasons similar to those I mentioned in the first paragraph above.