On December 9th, Bitcoin Core developer Luke Dashjr tweeted that the OP_RETURN discussion is not new and can be traced back to 2014 when Bitcoin Core 0.9.0 was released. It included the OP_RETURN policy aimed at preventing more malicious forms of spam. At that time, 40 bytes was the default maximum data carrier size limit implemented by all nodes, which was sufficient for binding data with transactions, both then and now (hash value 32 bytes, unique identifier 8 bytes). The core later voluntarily increased the default value to 80 bytes, and it never contradicts the design goal of creating provable, trimmable outputs with OP_RETURN to minimize the damage caused by data storage schemes, which have always been considered abusive behavior. There are also other good technical reasons why I choose to keep the lower default value of Bitcoin Knot and no reason to increase it.
Neither I nor the OCEAN team intend to filter mixed coinjoin transactions. These provide an innovative tool to enhance Bitcoin privacy, and when built correctly, coinjoins can easily stay within the OP_RETURN limit (in fact, they have no reason to have any OP_RETURN data at all). I have some ideas on how to mitigate the recent problem, that some coinjoin transactions are marked as spam by Knots v25, and I am willing to use all the resources of my team to sincerely cooperate in devising a solution.