For all it’s worth, if the PR to add NullMarked support gets merged and I upgrade to the version with the fix, most of the issues (metals override autocomplete causing flexible type spam) would be fixed.
In the wild I do see Kotlin libraries restricting their input types. It seems Kotlin’s extension syntax rejects null by default as well (doing fun String.foo() rejects null, need to do fun String?.foo() for null) which makes sense, because most functions that take a receiver usually want the receiver to be non-null (of course this is already achievable with explicit nulls now for concrete types).
There are quite a few use cases that could benefit from a nonnull type, I think the reason we don’t see it more in Scala right now is because it’s so obscure (AnyVal | AnyRef is a mouthful). I think discounting it as “not useful” isn’t really helpful - it’s never really had an opportunity to shine in Scala.
We haven’t mentioned making Null !<: Any in this thread, but the general sentiment was that “it would nuke the type system”. My main issue I see with that is we need Null <: Matchable and we aren’t adding “actually universal traits” to Scala anytime soon considering how “exciting” the base feature was. It would arguably make more sense from a ideological standpoint (or whatever nerdy standpoint I’m actually trying to say here) but that would be such a major change to the type system (even more than explicit nulls already does) that it would likely be more effort than its worth.