This article was originally published on 9 January 2019 on Honest.cash.
Background
Bitcoin Cash split from Bitcoin Core when the latter was about to activate SegWit. It also shared the same address format, and SegWit addresses are often in the pay-to-script-hash (P2SH) form (starting with 3) that also works on Bitcoin Cash, but of course Bitcoin Cash doesn't actually support SegWit. This let to people accidentally sending BCH to SegWit addresses, creating a transaction output on the Bitcoin Cash chain that "anyone can spend", provided one knows the public key behind the script hash. Safe recovery of these BCH coins consequently required cooperation with a trusted miner, as it does not involve a signature.
As of January 2018, Bitcoin Cash has its own address for the P2SH format named CashAddr (starting with q or p) that does not work on Bitcoin Core. Meanwhile on Bitcoin Core, native SegWit addresses (starting with bc1) have become more popular, which are not in the P2SH form and thus do not work on Bitcoin Cash. These accidents have therefore become easier to avoid. However, because some Bitcoin Cash services have been slow or reluctant to switch to the new CashAddr format, many wallets still support sending BCH to addresses in the legacy format, which could potentially be SegWit addresses. The accidents can thus still happen.
A plot twist
Perhaps surprisingly, the recent November 2018 upgrade of Bitcoin Cash made the problem worse. Namely, the BCH coins resulting from an accident are now "no-one can spend" instead of "anyone can spend", so even a trusted miner can no longer recover them for you. This is a side effect of the new clean stack rule that partially solves third-party malleability.
Third-party malleability is a man-in-the-middle attack where any relay node can modify some parts of the contents of a transaction as it gets relayed, without involvement of the sender, receiver, or even miners. This complicates handling 0-conf transactions and is obviously something we want to solve, but now some people fear about loss of BCH coins in SegWit accidents and consider reversing the rule change.
The sustainable solution
The much simpler and much more sustainable solution to this problem is to end the SegWit accidents once and for all. I think this is surprisingly easy:
Refuse sending BCH transactions to addresses starting with a 3.
Bitcoin Cash services that don't yet support CashAddr likely use pay-to-public-key-hash (P2PKH) legacy addresses (starting with 1). These have no risk of SegWit accidents and wallets can continue to accept them as inputs. The most common use case of P2SH (starting with 3) other than SegWit is legacy multi-signature wallets, but their usage is relatively rare, especially for hot wallets. Refusing sending transactions to addresses starting with 3 will thus have minimal impacts on backward compatibility, while it completely eliminates SegWit accidents.
So, in short:
Bitcoin Cash wallets should refuse sending funds to P2SH addresses in legacy format (starting with 3). Any option to override this should be hidden in advanced wallet settings where no noob can accidentally disable this safeguard.
Bitcoin Cash address convertors should warn to not send funds to P2SH addresses converted from legacy format (starting with 3) to CashAddr format (starting with p). Such address conversion should only be used to analyse transaction history, not for creating new transactions.
In rare cases Bitcoin Cash users still encounter P2SH addresses in legacy format (starting with 3), they should ask for an address in CashAddr format before sending any funds.
This allows Bitcoin Cash to move forward without risking irrecoverable loss of funds.
Known implementations
You are totally right. Sending a transaction to an address beginning with 3 should not be possible on BCH, and its only a result of the shitty btc copypaste code and now nothing can really be done as such transactions already got recorded in the blockchain. However the node should not relay any of these transactions, and i dont even understand, why they do. Half of the new features or bugfixes from the last years were about fixing fake problems and adding unnecesary features, and those took away the time from the actual work (there was of course useful upgrades as well).
The opensource (communist) model of programming sometimes favors contraselected clowns as everyone can commit code, and they race to try committing the most snowflake solutions instead of actually developing, programming, and trying to make a better, faster, economically more viable solution. Cryptocurrency related codes are literally the worst quality i have ever seen, like quitting for cycles with goto, calling a complex size determining function in every iteration in the cycle head even if it never changes so the code will run for 10 seconds when it could run 0.1 seconds, people who lack to understand even what bits, bytes, instruction sets are, makes worse quality than what a 12 year old autistic kid from a computer club would wrote, whose mom was droing heroin during her pregnancy.
Of course i dont want to diss the actual people: these people are NOT programmers. They are cryptographists and mathematicans! Luckily, they can do a little bit of coding. And the REAL programmers cant do anything, because they don't understand cryptography or this high-level math as a science, as a concept, therefore they cant write proper node solutions. This means that until cryptocurrencies are cryptocurrencies, we will have to live together with the shitty code quality and almost zero realibility, and the responses on bugreports will be delusional ravings from people who can understand 600 page long academical papers with hierogliph-like mathematical symbols knowing their only friend is a pet cactus they forgot to water since 2008.