Replace-by-fee (RBF) is the ability to broadcast, propagate and ultimately get a replacement transaction in a mined block instead of the original competing transaction that you originally broadcast. It has been possible to do this from the very first Satoshi client because when presented with two competing transactions that meet the consensus rules miners can choose which transaction they include a block they attempt to mine. Generally it makes sense for the miner to include the transaction with the higher fee rate in the block regardless of whether it was first seen or not.

[BIP125][1] formalized RBF into a specification back in 2015. It introduced the ability for a transaction to signal whether the sender wanted the transaction to be replaceable or not. It wasn't a consensus rule change so miners could still choose which transaction to include a block and ignore the transaction signaling assuming it saw both. However, Bitcoin Core and other Bitcoin implementations (with some exceptions e.g. Bitcoin Knots) implemented the ability for full nodes to check whether the original transaction was replaceable before including a replacement transaction in its mempool and ultimately propagating the replacement transaction across the network.

Zero confirmation merchant acceptance ensures a better UX for a merchant's customers as you don't force the merchant's customer to wait for confirmation(s) before the customer can leave with their purchased item or service. The security it offers the merchant is significantly less than the security of a single confirmation let alone multiple confirmations. With zero confirmation it is trivial to broadcast a competing transaction ("double spend") that doesn't send any funds to the merchant. It is then a race to see which transaction gets included in a mined block and whether the merchant receives the funds they are entitled to. However, merchants have argued that this doesn't happen as commonly as one would think and it is possible to manage this risk in the same way as credit cards manage chargeback risk in the fiat economy. It is difficult to assess why it hasn't happened that much historically (assuming it hasn't). Transaction fees have generally been low and miners generally haven't offered an ability for users to send transactions directly to them bypassing the P2P network and mempool policy enforcement of RBF transaction signaling. These may have contributed to zero conf risk being manageable in the past but clearly aren't guaranteed to continue in the future.

Second layer protocols such as Lightning rely on the ability for a user to get a transaction confirmed in a timely fashion in an emergency scenario such as a channel counterparty broadcasting a revoked state in a Lightning channel. Hence Bitcoin protocol and Lightning protocol developers have been studying what default mempool policy would be optimal to bolster the security model of those protocols. Many of them have assessed that the RBF signaling introduced in BIP125 overcomplicates this work and introduces unnecessary edge cases which would be eradicated if the RBF signaling was simply ignored by Bitcoin full nodes. Recall that miners can already ignore the RBF signaling without contradicting the consensus rules of the network and risking being forked off the network or causing chain splits.

Hence a `-mempoolfullrbf` option was introduced in the Bitcoin Core 24.0 release which would allow full node operators to ignore RBF signaling on transactions and accept replacement transactions into their mempools regardless of whether the original transaction was signaling for RBF or not. In Bitcoin Core 24.0 it is off by default but node operators can turn it on to ignore the RBF signaling of transactions. 

An alternative would have been to turn it on by default and allow full node operators to be able to turn it off but with multiple merchants currently providing a zero confirmation UX to customers this could have resulted in many more replacement transactions or "double spends" being propagated across the network than if the option was turned off. It is possible the default could be changed in a future release but that would be subject to the Bitcoin Core review process. Merchants relying on zero confirmations clearly aren't enthusiastic at the prospect of more replacement transactions potentially being propagated across the network and so have opposed this change. This is unfortunate but it is a rare example of a change where multiple trade-offs have to be weighed. Post the block size war in 2015-17 it was generally accepted that Bitcoin needed to scale on higher layers such as Lightning and so the security of those protocols was prioritized here over what many consider to be a flawed business model in the long term. It is important to stress again that this a mempool policy discussion and not a consensus discussion. There is no chain split risk with mempool policy changes and so from the vantage point of the blockchain and the network this is a low risk issue. However, for merchants relying heavily on zero confirmations this is something they need to take seriously going forward. Arguably they should have been planning to reduce their dependence on zero confirmations regardless in the long term but the introduction of the `-mempoolfullrbf` option in Bitcoin Core has brought this issue to the forefront.


  [1]: https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki