Ossification is the feature

Maybe that's because I'm not one :)

Mostly right, a few comments:

• The overhead to publishing data in an Inscription is bigger because you first have to make a commitment in the output and then create a P2TR scriptpath spend to reveal the inscription. After paying for that, the data is subject to the witness discount, so the data bytes only weigh one 1 weight unit. OP_RETURN outputs are not subject to the witness discount, so they weigh 4 weight units, but they have less overhead. So, smaller data payloads are slightly less expensive to be published in OP_RETURN than in Inscriptions, larger data payloads are cheaper to publish in Inscriptions. The border between the two is around 144 bytes. So, this change would make it slightly cheaper to publish data payloads of up to 144 bytes, and make no difference for larger payloads as they would continue to be published as inscriptions, assuming the sender optimizes for cost.
• Since hashes and public keys mostly look like random data, people have been using them to publish very small chunks of data since pretty much forever. Such payment outputs cannot be discarded, because they are theoretically spendable, and if one were spent, it would split the network between nodes that accept the transaction and those that do not. Therefore they are permanent additions to the UTXO set, which represents the minimal state that every full node must retain to validate transactions. For extremely small data amounts, the overhead of fake payment outputs is similar to OP_RETURN outputs, but it’s slightly more expensive. By dropping the limit on OP_RETURN outputs, it is always be cheaper to publish data into an OP_RETURN than to publish it into a fake payment output. OP_RETURN outputs do not need to be stored in the UTXO set, because they are provably unspendable.

So far their reaction to the evidence has been to continue claiming that filters work. I have not seen anyone actually propose a fork over this, but I doubt that a hard fork would be necessary. Forbidding things only takes a soft fork. 100% Knots would be insufficient if the people that want bare multisig directly hand them to miners who include them in blocks.

I don't think Knots supports a hardfork, but maybe I'm wrong because I'm fully off the social media dumpster fire (for 2 days because I felt the need to provide a pointer on nostr re: coinos)

Have you got any reference of Luke saying he'd support that?

Wouldn't Knots need 90% nodeshare... to filter the bare multisigs?

100% miner share.

am pretty sure (although I am not an expert by any imagination) that unspendable UTXOs was the primary reason for the recent delimiting of op_return...

Correct, but counterparty has been doing this (with 1-of-3) for a longer time (Note: I suspect it still does but honestly it's been over a decade since I last looked at that)