This one could be an issue -- SwitchParameter is a very widely used public API

But SwitchParameter is immutable by design, and adding the readonly-modifier doesn't cause any overload resolution changes [1], so I think this is not a breaking change.

[1] https://blog.paranoidcoding.com/2019/03/27/readonly-struct-breaking-change.html

Ok I'm fairly convinced by this

I'm not sure about changing public structs to readonly -- existing code that relies on the previous form may be affected

This struct is immutable by design.

Changing the signature on a public method like this is a breaking change

The compiler doesn't permit overloading on ref/out/in differences, so this change is non-breaking.

Technically the issue isn't with the compiler, but with the runtime. Modules compiled against the old API surface must continue to work after any changes are made to the API.

But I tested it out with a toy project (an exe and a lib, where I built an in version of the lib and then changed it so the exe is compiled against a ref version) and it seems to work.

The in, ref, and out keywords are not considered part of the method signature for the purpose of overload resolution. Therefore, methods cannot be overloaded if the only difference is that one method takes a ref or in argument and the other takes an out argument.

Yeah that's still C# compiler rules, where the compiler statically decides which overload to resolve for a call. My concern was that the resolved method call in the IL might not match what the library was originally compiled against when its loaded at runtime (so even though the original program isn't broken it still requires recompilation, which is a dealbreaker for modules). It makes sense that that's not the case though.