There are two PRs, one which leaves a setting but unlimits it by default.
Thanks for the info. Imo that makes sense ...I'm not really that opinionated on leaving a useless option in, though because of the character of the response I do lean towards removing it: Removing it is simpler, results in less complexity.
I wonder if there are stats about the usage of the datacarriersize parameter. It should be possible to estimate it at least. If it is popular then in my opinion it isn't useless. I think even if it is technically useless because miners would normally mine these transactions anyway, people could simply "feel better" if they can keep out some things from their mempools (even if their nodes would broadcast happily PEPEs and other JPEGs created with Stampchain). It's however debatable if these nodes should be called "full" nodes.Perhaps less good reasons, conceding to an attack driven by misinformation or collateral concerns creates ongoing risk.
I think I understand your reasoning here, but I think perhaps a concession can also be helpful sometimes to calm the waters. I'll try to read a bit about how the block propagation problem and the OP_RETURN limits are connected, as this is still a "hole" for my understanding of the whole context.Sadly I somewhat agree with this, which is what I've warned about before; and it's only because the core devs didn't act when they should have acted!
No, that's not what I meant.A "patch" like the one Luke-jr proposed is just the kind of code I don't want to see in Bitcoin Core, ever. It is a hardcoded "filter" which would only target a specific format of Ordinals inscriptions, and they could come up all the time with new versions which also would have to be patched, this is what @gmaxwell probably refers to as a "whack-a-mole" game.
I guess if the Ordinals wave would have begun, and Core "patched" it let's say in March or April 2023, then the Ordinals folks would have massively switched to Stampchain (which was already around in early to mid 2023) for NFTs and existing protocols like Counterparty (not a harmful method, but could have created a similar spam wave) for tokens -- take into account that the big majority of the "spam wave" was due to BRC-20 tokens which doen't need the "extended Taproot witness size" to work. Stampchain later even created a token protocol (SRC-20), and we can really happy that that one never really took off, it would have caused even more stress to the UTXO set.
But I still don't see how encouraging people to inject arbitrary data of any size and without limit into bitcoin blockchain which would be treating it like cloud storage is a good idea.
First, OP_RETURN data must also respect the general size limit for transactions even if the standard setting is set to "unlimited". As the maximum limit is 400k WU, this puts OP_RETURN (where afaik 4 WU are "consumed" by each byte) still not on better terms than the Taproot witness method (where up to 400 kB are considered "standard").And second, why should the least harmful method to store data be the most limited one? As you can see it would still be more limited than the Taproot method, but at least it would be on similar terms with Stampchain which nowadays is at advantage regarding OP_RETURN.
And like I always say bitcoin is not a cloud storage, so we should make it harder for them to use it as such not easier (ie. removing OP_RETURN limit). 
What exactly becomes easier if the OP_RETURN limit is lifted? There are lots of tools to use the Taproot exploit now, and also lots of tools to use Stampchain. It's not hard at all to use these methods. Nothing of this becomes easier if the OP_RETURN limit is lifted.Again, it's only to put the least harmful method, OP_RETURN, on similar terms to the more harmful methods like Stampchain.