A summary of their positions

Yes, the repository is, quite literally, our workplace. We encourage other people to also make it their workplace. We are happy for people to follow along or constructively contribute, but people that don’t work there are guests. We expect some minimum decorum from our guests. We handle disagreement well, and disagree among each other often enough, but someone standing in your office repeatedly shouting crackerbarrel talking points at you without making an effort to understand their discussion partners’ view points doesn’t cut it.

I’m not sure who you mean when referring to a former maintainer. I’m aware of ariard getting banned recently, and BitcoinMechanic being banned for a day to cool off. I support the former moderation action and the latter seems perhaps a tad heavyhanded, but 24h pass quickly.

I don’t think anyone is making claims about the moderation being for the benefit of Bitcoin, IMHO the moderation is for the benefit of all participants in that pull request. Collapsing repetitive and vacuous comments improves the signal ratio of the discussion and makes it easier for people to catch up to the content of the discussion.

IMHO, Bitcoin Core contributors generally have tough skin, and most don’t seem to have trouble sticking to "criticizing ideas instead of people". Working in public can be rough and frequently being wrong in public is humbling. That doesn’t mean that we need to subject ourselves to gratuitous abuse, or that it should be required for us to read dozens of crackerbarrel quality comments on every controversial topic to keep abreast of discussions.

Everyone gets to decide for themselves and our moderators decide for the repository. How about these for a starting point: before posting, read all of the previous comments. If the comment you're in the process of writing only repeats prior points, leave a reaction on the corresponding comments instead. If your comment is about politics or conspiracy theories keep it on social media. If you find yourself attacking people instead of ideas, take a walk before taking another stab at your comment.

What "bug" are we referring to? AFAIK, Luke is the only Bitcoin Core contributor that thinks that a configuration option that was introduced twelve years ago to allow configuring specifically the OP_RETURN size a node accept in their mempool should obviously refer to any new patterns that are used to insert data in the blockchain, and classifies the appearance of new patterns that are not yet handled by the code as a "bug". I really don’t get how that position got picked up by Bitcoin Twitter so broadly—it’s a comically absurd representation.

I guess you could describe it that way. I would say that it’s based on a non-emotional assessment of what’s happening on the network. Since Ordinals, Inscriptions, and Runes have started, these transactions have paid about ~$286M (7,050 ₿) in fees and occupied between 5–40% of blockspace.

One of the tenets of Bitcoin is censorship resistance, and in this case, it works well for the NFT-enthusiasts: about 10% of nodes accepting and forwarding their transactions is sufficient for transactions to ~reliably propagate to miners. Miners have a big financial incentive to include these transactions, miners that do not include them take a paycut and increase the revenue of other miners. (I believe this to be self-evident: taking only a subset of the juicy transactions means that the average fees collected by your blocks being lower, and leaves more high feerate transactions to the next block.) When the Ordinal craze started in early 2023, the reachable node count jumped up by several thousand nodes. This implies that even if Bitcoin Core started releasing node software that filtered Inscription transactions, there would likely be sufficient nodes that forward them, simply by those people not updating their nodes. Beyond that, the business with these pictures is probably in the billions if they already pay hundreds of millions in transaction fees, and that is plenty money to organize a patched client that forwards the transactions. That means that even a majority of nodes filtering these transactions would not make any dent into their likelihood of making it to miners.

The Bitcoin community could try to bring out the big guns and soft-fork the transactions out, but with soft forks generally taking months to years to deploy, and there being many different ways how such data carrying transactions could be created, the NFT enthusiasts would likely be more nimble and simply switch to another script. We could restrict transactions just to a small set of whitelisted output scripts, but data could still be embedded in the hashes used by those output scripts, and losing the ability to have programmable money would be too big of a price. There is an argument here, that forbidding one type of NFTs might be sufficient pushback to make the community feel unwelcome, but I doubt that it would turn out that way, if I look at the resurgence of Stamps when Ordinals were popular and consider that there are three more such protocols since.

So, trying to "filter" these transactions so they don’t get into my node’s mempool, while I still accept them in my blocks doesn’t seem useful to me. I don’t buy that it actually saves bandwidth, because I still have to download the transaction once and will forward it with any blocks I relay. It might actually increase the traffic, because almost all of my peers will still announce the transaction to me. It makes my node a less useful peer and makes it minusculy slower for me to receive blocks because it causes the compact block relay to never succeed fully. On the other hand, I no longer have a complete picture of the mempool, to see what my own transactions should be competing with, I cannot predict the next block accurately anymore. Out of these advantages and disadvantages, it seems at best like a toss-up unless I have some sort of emotional reaction about sticking it to the funny picture people by not having their transaction in my mempool (but still in my blockchain). Anyway, it seems useless to get all wound up about this, especially now that it has mostly run its course. It’s not exactly new anyway, we’ve had multiple waves of colored coins, timestamping schemes, and NFTs on Bitcoin in the past ~13 years that I have been around—they just taper out when the respective set of people learn that blockchains don’t work well for data storage and get tired of paying for it.

Regarding the classification of doing inscriptions as "bugs": characterizing the possibility of doing Inscriptions as a bug seems silly, unless you are advocating to remove all custom scripting, and I have already explained why that doesn’t seem right to me above. On the other hand, the datacarrier configuration option was specifically introduced to regulate the size of OP_RETURN outputs, so suddenly claiming that it should apply to any transaction pattern that might be used to put data in transactions even while the methods’ costs are wildly different is charitably at best a new idea—I am not aware of any other Bitcoin Core contributors that share that interpretation.

So yeah, the whole Ordinals, Inscription, Runes, and whatever stuff is not great, but if there is significant demand for creating those sort of transactions and they already show up in blocks, instead of trying censor part of the bitcoin users and thereby incentivizing them to start running private mempools or building tools for direct submission to the bigger miners, I’d very much prefer relaying their transactions on the open network so that all miners get them into their mempools.