Yup, unfortunately for us there is a lot of C# code written without NRT. If all of your code utilizes NRT and you respect the warnings, you can nearly eliminate issues related to null. There are some paper cuts around generics, but generally it has been working quite well for me. Our entire code base has NRT enabled and the only place where null sneaks in is with EF Core missing includes. This is actually kinda nice because if you get a null-whatever exception, 99% of the time it's a missing include.

This is true, but you can fairly easily audit your solution for files/projects which have it disabled. And yeah, you need to verify the data at the boundaries of your trusted code - but that's the same situation as it's always been. Where NRT help is avoiding boilerplate null checks in the dense forest of your business logic.

Well my point is more that if they introduced an entirely new non-null reference type to the language then you could never make that mistake - it would be non-optional for those calling into your code to respect whether null can be passed in or not based on the type you used. Since they instead made it an optional system you can not rely on those using a library you make to actually turn it on, you have to accept that null _can_ be passed in even if you mark something as non-null according to the system on your side, which is dumb.

Yes, that is possible but you still get warnings and you should compile with warnings as errors anyway.

You only get warnings if you turn those on, you can use `<nullable>disable</nullable>` and then the language works exactly as it previously did. In fact, when you disable it you get warnings if you _use_ the nullable system and mark a reference as `?`.