Best solution? You can make a case that implementing BIP-110 turns one problem into two or more.
Currently: "Spammer" creates one TX and puts data in op_return. Data gets pruned by non-archival nodes.
BIP-110: Instead of one TX with that op_return payload, they chunk it across multiple transactions and/or even worse, use fields outside of op_return.
Result: While you were aiming to save archival node bloat, you now introduce bloat elsewhere. First, if they use other fields like witness data, you now have UTXO bloat for data that cannot be pruned. Second, by forcing additional transactions to do the same work, you ramp up CPU/Memory overhead bloat, which could stress fringe (older hardware, RasPis, etc) endpoints.
Fees also likely increase because more transactions are being submitted driving up costs for those monetary transaction users. Look, do I want Bitcoin used for this shit? No. But do I get the technical realities and what Core hoped to accomplish? Yes.
If you believe I'm wrong with the above line of thinking, by all means set me straight.
