Comment by WorldMaker

Yes, the article itself even points out that the C# default has always been to make the unsafe keyword a compile error by default and must be opted in at the project level to even use it. So most C# application code doesn't use unsafe.

The benefits here are mostly to specific types of libraries, often either deeply performance-focused libraries or complex native interop libraries (things that wrap C/C++/Rust/etc code as a .NET Library).

The article mostly also points out that like Span<T> many of the biggest benefits to application writers here are going to be making the runtime itself quietly better (faster and safer). The new compile errors will make Base Class Library code and runtime code more auditable for potential memory safety issues by bubbling up safety concerns higher into the code stack and making the boundaries between the unsafe and "safe" code much easier to find. It will provide additional incentive to narrow the number of things that need to be marked `unsafe` and provide extra incentive to the runtime to minimize `unsafe` dependencies. This includes adding additional weight furthering the push for rewrites from "performance" C++ code (under the hood of the runtime) to memory safe C# code with modern safety/performance tools like Span<T>, while also reducing some of the similar pressure to rewrite that C++ code as Rust for memory safety reasons rather than directly to C# (with less overhead of transitioning to/from "managed code" and "native code") by providing similar `unsafe` safety marker tools to what Rust has had since 2024.

(ETA: There may still be some possible breaking changes to today's application code when opting into the new safety checks though by adding possibly more uses of the unsafe keyword than were needed before as many APIs with unsafe in the name or documentation such as the Marshall.* family of functions will probably get new safety documentation. Most of those concerns are still in P/Invoke and native library interop spaces and would probably be refactored into libraries to re-isolate the unsafe code and have the application continue to not allow unsafe blocks, but that will be tech debt migrations that may show up when opting into the new behaviors.)