Wondering if this whould go under a feature flag, since technically it may change the codegen.

I consider it more of a fix. Basically the current way does not fully understand what Roslyn can do with respect to the "readonly" keyword and possible placement of [ReadOnly] attribute.

See example here - even placement of readonly keyword at the method level (which existing code is supposed to support) gets overriden by readonly on struct level, and therefore method does not get the [ReadOnly] by Roslyn.

Wouldn't IL tests be more reliable? The warning could theoretically be broken (or its behavior changed), independent of whether or not the defense copy is emitted.

This was the only part of the test suite that failed when adding this feature, that is why considered it.
You mean searching IL output and scanning that there was no copy instruction at all?
Or comparing strict equality of the entire generated IL?

Just something simple like https://github.com/dotnet/fsharp/blob/main/tests/FSharp.Compiler.ComponentTests/EmittedIL/EmptyArray.fs, to show the instruction is present when expected, and missing when dealing with readonly structs.

Just something simple like https://github.com/dotnet/fsharp/blob/main/tests/FSharp.Compiler.ComponentTests/EmittedIL/EmptyArray.fs, to show the instruction is present when expected, and missing when dealing with readonly structs.

Thanks, this is the way.

I do agree this can count as a bug fix

Could you add test cases for extension methods on readonly structs please?

I do agree this can count as a bug fix

Could you add test cases for extension methods on readonly structs please?

Works.
For F# defined (even if C#-style) extension methods, the entire call gets inlined.
For C#-lib defined extension method, and consumed from F#, it works as desired = defensive copy avoided for readonly struct.