Only way of creating such a fail safe is to make the output a 2 of 2 multisig in which the sender can redeem before or after a specific lock time and the second signer can redeem otherwise. The problem is that this assumes you have properly formatted your script and are sending to the expected one. In the case that you send to the WRONG script, it's impossible to recover unless that wrong script has this time-lock recovery spending condition. Miners accept ANY valid transaction or else bitcoin would be censorship enforcing.

I think the fact that its prohibitively expensive is the main point I was hanging on for why no one would do it on bitcoin, but on low hashrate altcoins of course!

Well there have been significant improvement to transaction propagation and output selection in the core software that will likely be mitigating against these attacks in real time. I personally do not think that this niche tech-art is going to threaten the current state of the network especially since it is highly ineffecient, is likely a zero sum profit game, requires centralized systems to operate, and seems to carry little to no social weight amongst organic bitcoin users.

Things like this are kind-of annoying but I think the network has succeeded in preventing these types of issues from becoming a major issue.

This right here is a fantastic security assumption when burning bitcoins.
If we really want people to be CONVINCED of the coins being burned IMMEDIATELY (not after the coins weren't moved for 20 years) then we need to burn them with a OP_CODE that makes the coins verifiably non-spendable.

Using the likeliness of the private-key not being recovered from the public key is really not enough as people can easily fool people by using keys which merely look like burn addresses. Users wont verify them and will end up sending money to a scam. If coins are consensus level non-spendable there would be no chance of this.

Lightning network works through a concept called Atomic Multi-Path Payments:
https://bitcoinops.org/en/topics/atomic-multipath/

These are effectively payment channels secured by multi-signature, they start on chain with a channel opening commitment:
https://docs.lightning.engineering/the-lightning-network/liquidity/manage-liquidity#channels

This is the start of the on chain portion of lightning.

The off chain lightning network is enabled once these channels are established, re-balancing channels is an example of an off-chain task you can do with the established channels:
https://docs.lightning.engineering/the-lightning-network/liquidity/manage-liquidity#rebalancing-channels

Once a user wants to settle the funds back on the main bitcoin chain they need to initiate a channel close:
https://docs.lightning.engineering/the-lightning-network/liquidity/manage-liquidity#closing-channels

There are two options for this, a cooperative close:
```
In a cooperative close both nodes are signing a new commitment transaction and publishing it to the network. The on-chain funds created in such a transaction will become available for a new channel opening almost immediately. In such a case it is also possible to set the fee with the --conf_target or --sat_per_byte arguments and define which address the funds should be sent to via --delivery_addr (unless this was already specified at the channel opening).
```

And a force close:

```
When closing a channel unilaterally, known as a force close, the funds will be locked up for a period of time before they can be redeemed by the closer, while the other party can redeem their funds immediately. Unless an anchor channel was created, you are unable to change the transaction fee of the closing transaction. To force close a channel use the --force flag.
```

Both of these closes involve finalizing the state of the atomic multi signature script committed to by the members of the channel on chain.

Using 1:1 bitcoin is the same thing as using bitcoin there is literally NO DIFFERENCE

This is actually not an accurate distinction.

For example the lightning network is NOT a side chain it is a layer 2 and it uses real bitcoin and nothing else to make transactions.

The liquid network IS a side chain AND uses real bitcoin AND uses other currencies which it can create through covenants.

The rootstock network IS a side chain, uses real bitcoin and also allows for other smart-contract style assets.

Effectively both need to use the native currency of the base layer in order to operate AT ALL.

To go into consensus algorithm, a layer 2 generally does not implement consensus it WORKS WITH the available consensus at the base layer.

Side chains on the other hand REQUIRE a consensus mechanism as they are distributed chains of their own who need Sybil resistance in order to work.

Lightning doesn't have a "consensus mechanism" but they do have a TON of best practices for not allowing your atomic multi-path payments to become lost to counter-parties. All of this work is settled on the base layer of bitcoin so anything that happens in the lightning network happens at the whim of each individual user and their responsibility.over their assets on the channels.

To talk (briefly) about Ethereum (please dont discuss that shit here there's a dedicated altcoin space)
They have a few "roll ups" which are effectively groups of trusted parties who allow multiple users to batch transactions from the l2 to the main chain in one transaction. This is problematic because the trusted parties and the l2 itself become a censorship (and other exploit) vector because they behave effectively like an account with custody control. Since there has been NO attempt to build sybil resistance at the l2 layer on Ethereum (or at the base layer for that) and there has been no attempt to create a side-chain on Ethereum (because their community does not believe in distributed decentralized consensus mechanisms) you can HARDLY call any of these implementations a REAL l2 .

This is confusing to say, Polygon is both a layer one network and a side-chain on Ethereum. (Although I think it is highly centralized technology and do not recommend anyone use such a thing)

You can manipulate a timestamp relatively easily since you are submitting work to a network that does not know when you did that work. That being said they CAN for example ensure that you are not setting a time that has not happened yet. They can also ensure that your timestamp falls in between the acceptable window for solution times based on previous block times. Since this window is relatively large compared to the average block time, "pre-mining" works would be highly improbable for anyone to pull off since they would essentially need to solve the block before everyone else on demand and then submit them delayed which decreases their chance for propagation.

To commit work you need to include a public key that is used as the collection address for coin-base / mining rewards.
Assuming that you would never use someone else's key (or that the whole network would never use  a single public key) every commitment of work will LOOK different even if they (miraculously) ended up on the same hash collision. Not to mention the ability to publish this block means that they get to commit their transactions from the mempool to that block, therefore each block will also vary in how it appears to other nodes.

I think its obvious the ordinals deployers attempt to waste block space which will naturally be rejected by users over time so it doesn't matter how any of us individually FEELS about it, if it is not helping the blocks churn 10 minutes at a time they will die out due to Darwinian evolution. That being said overall just using the chain to store a reference to other data seems just fine, but spam is spam and will be treated as such by organic users of the network. Such a thing could be done 100x more efficiently on a side chain.