Unusual segwit transactions

So, it looks like someone is sending out segwit transactions with some nonstandard outputs. Here are a few examples: https://mempool.space/tx/e57619adbb62c2e8add13eb2694010f3ba337cf5007ca3674224c272feffb097 https://mempool.space/tx/9a9d955dff45c6cef6f4e41a12052dde21179069a2e17fe8f381f6c75e112b6a https://mempool.space/tx/e6107730017b2b84e187add5c3fed5a71edcda0b85b982297282137fe0480234 etc. The output scripts look something like this: OP_PUSHNUM_14 OP_PUSHBYTES_40 f88301874465706f73697483313a30b83e626331707938767865376563776a74646c76636372656 b OP_PUSHNUM_14 OP_PUSHBYTES_16 b41f990a5dd60458ad5f030f2a78b7d3 Clients seem to treat these as standard (segwit version 14) and pass them along. Not sure if that’s how it should be, but maybe it makes sense to add some filters for clients so they don’t include transactions with unknown segwit versions in blocks by default?

Sending to new Segwit addresses was always standard. However, spending from them is non-standard. Older example: https://mempool.space/pl/address/bc1sw50qgdz25j And then, when a new address type will be officially introduced, it will be harder, because old clients wouldn't allow sending to them. For example: if you have pre-Taproot client, it can still send coins into Taproot, as long as it has Segwit implementation. The same with recently added anchors: https://mempool.space/address/bc1pfeessrawgf And also, there are reasonable limits, for example you cannot have a Segwit address with more than 40 bytes, so it is two times smaller than OP_RETURN limit (so, if anyone would want to spam, then that person would abuse OP_RETURN anyway).

I know. But there is absolutely no reasons to send bitcoins to such unspendable yet address. For what? Increasing the size of utxo set? Burning small amounts? Seems to me, that the transactions above are the result of some broken engine (f*cking runes!) I think it will be better to change the policy rules in core client.