Exactly. FULL tasks but not necessarily "original data". OP_RETURN in Bitcoin consensus rules means "everything behind that is irrelevant". So if something is irrelevant it should be outside of the scope of a fully validating node. That doesn't contradict that there may be other kinds of nodes which do see some "sense" in data stored behind OP_RETURN.

My thoughts on that were more related to the whole Bitcoin ecosystem, i.e. not only including miners but also the whole use case landscape. And the marginal benefits that miners are incentived to provide a little bit more security for some more weeks are imo outweighed by the negative impact on several user groups (not all - runes users are also users). If the incentives accelerate the creation of more and better L2s however (which solve the problem almost completely), then Runes are positive. This has to be confirmed though.

I think yes this is correct - Luke's Knots client correctly recognizes also Ordinals-type data (embedded in witnesses), but for Runes the normal Core option is enough because Runes uses OP_RETURN and Core's datacarriersize option restricts OP_RETURN size. See Luke's proposal here.

This is actually one thing where I think Luke is correct, this is the way to give nodes the ability to restrict data usage, not some hard-coded heuristics which have to be updated all the time. But the importance may be limited as most would use the default value which is 80 bytes, and allows Runes.