In fact things like this are the reasons why I've argued for the benefits of having a strong alternative implementation of the Bitcoin protocol to be used instead of core...
There are fair amount of alternative Bitcoin full node software, but for better or worse Bitcoin Core is still very popular. I've tried few alternative in past, but still prefer Bitcoin Core.
Bitcoin should stay lean. If more data is needed, Layer 2's can batch it and use OP_RETURN more efficiently.
Bitcoin L2 isn't that popular though, with varied degree of trust/centralization[1] and even falsely pretending as Bitcoin L2/sidechain[2].
[1]
https://www.bitcoinlayers.org/[2]
https://www.lxresearch.co/starting-to-define-layers-a-year-later/Looks like Bitcoin Knots may be a good way to protest against this. It has Bitcoin Core functionalities and you are actively voting against this PR by running a node. We should do that but also try to stop this on Bitcoin Core itself from being merged. Bitcoin is not some experimental blockchain to host jpegs. It's clear to me now that the whole argument for this PR is, "the blocks are empty so we must come up with ideas to fill the blocks". This is just linear thinking. The demand for using BTC for it's real use case, which is to move and store money, will be an S curve, and when it happens, you don't want the blockchain cluttered with jpeg spam. This is a huge mistake and anyone involved will have their name next to this when it becomes evident.
Good videos:
https://www.youtube.com/watch?v=zgsiDAhq4d4https://www.youtube.com/watch?v=o7kCqwR9x24Bitcoin Knots is great, I've been running it for lightning node on Umbrel and also a standalone for onchain, both with datacarrier=0 since the Oridnal spam attack. Core should also fix ord injection vulnerability instead of removing OP_RETURN limits thinking that spammers will start using that instead. Providing witness discounts, making op_return standard, making it 40 bytes, then 80 bytes and now removing all limits is the real cat & mouse game they've been playing.