If we keep changing the basic rules where businesses are build on. there is no future.

Muun wallet simply needs to wait for a confirmation where applicable. Phoenix wallet does that and works fine; I personally recommend it over Muun.

As for other 0 conf services... Like what? There used to be a lot more. But they were getting attacked and gave up. Eg I haven't found an ATM that accepted zero conf for literally years. Nor have I found any in-person exchange services that accepted zeroconf without full AML/KYC.

Many years ago I did have some ATM operators complain to me that they'd lost a lot of money with zero conf though...

With RBF, I can look at the mempool and set the sat/Vb fee to the current minimum fee needed to be confirmed. As seconds or minutes pass, that fee may become inadequate. RBF lets me (or my wallet) increase the fee by composing a "replacement" transaction. This essentially assures me that my transaction will be confirmed in the current block (that the miners are trying to solve) without me having to pay more than was needed.

That's the good (for me). And that's what I want to see for bitcoin -- the assurance that time-sensitive transactions can be confirmed promptly, if I'm willing to pay.

Tagging a transaction to let known to the network that could be replaced later with higher fee transaction in order to unstuck the funds of being on the mempool for days when the network is congested.

RBF is basically a tag you put on the transaction notifying the receiver that you can later change the transaction if is not confirmed.

RBF exists today because bitcoin transactions cannot be canceled and they cannot be revoked. So without RBF, if you send a transaction and didn't pay a high enough fee, your transaction may take a long time to confirm, if at all.

RBF was later added so that you can have the option of sending a "replacement" transaction, and in that replacement transaction you can set a higher fee.

Back before RBF was introduced, lightning didn't exist and some merchants (e.g., retail / point-of-sale) were accepting an on-chain payment before waiting for confirmation (i.e., 0-conf, or zeroconf), as the risk of a double spend was low as it required either some skills or some participation of a miner to pull off the double spend attempt. So the approach was to make RBF "opt-in" to where, if a later transaction comes along and tries to spend a UTXO that is already in the mempool, if that mempool transaction is marked as "replaceable", then the node will consider the replacement transaction to be valid and will relay the transaction to peer nodes.

A transaction marked as replaceable is trivially easy to double spend. But because the transaction has that RBF flag, then a merchant can ignore transactions that are replaceable (until they have a confirmation) but still accept any zeroconf transactions that were not "replaceable" (which is the default for nearly all wallets).

This change in Core v24 will make it a configuration option to make all transactions be treated as replaceable. This negatively impacts anyone willing to treat a zeroconf transaction as a completed payment (which is the example of the retail merchant accepting zeroconf for point-of-sale purchases).

But the risk to accepting zeroconf has always existed. A miner could always double spend a transaction in the mempool. Let's say I am dishonest so I when I pay for my $50 dinner at a restaurant with an on-chain transaction, is set my tx fee at 1 sat/vB, knowing that because the mempool is congested my transaction likely won't confirm for hours, at the earliest. My payment didn't have RBF signaled so the merchant accepted the zeroconf payment. Then let's say an "unknown" pool with 10% of the hashrate says they will include any transaction regardless of whether or not RBF is set, as long as the fee paid is $10 or more. That 10% hashrate means they will likely get a block within two hours. So, I then pay $10 for the double spend transaction that I broadcast, and relay that transaction directly to that pool's node, and within a couple hours, I got a $50 dinner that only cost me $10. Again, that can happen today regardless of whether Full RBF exists. This change in Core v24 just makes it so that even if just a fraction of nodes have Full-RBF enabled, all transactions in the mempool are easily double spent (regardless of whether or not they had the "replaceable" signalling).

Muun Wallet, for example, will be one such bitcoin service that is against Full-RBF, as now their users sending an LN payment will not be essentially instant as it is today (as Muun is today willing to take the double-spend risk of the user's submarine swap transaction, but with Full-RBF, continuing to do that would be insane).