Right now, as specified in Java Interop Docs, Nullability Annotations section, only a pre-defined subset of nullability annotations will be checked by the compiler/parser to determine if platform types are marked as non-null or nullable.
I think it would be nice to allow any nullability annotation, named NonNull, NotNull or Nullable (coming from any package and not only from the pre-defined ones), to be able to specify the nullability of a platform type, since in IntelliJ IDEA, you can tell the compiler to use your own custom annotations for generating run-time assertions (in Settings > Build, Execution, Deployment > Compiler > Configure annotations…).
Or, at least, make the Kotlin compiler/plugin integrate with the IntelliJ IDEA settings, if available, and detect the configured annotations.
It’s more about being compatible with the IDEA settings than a critical problem. Since IDEA lets us configure our own custom annotations, then you can be sure that there is even a little small group of developers who use their own annotations (including me), for various factors (private libraries, hobby projects, reducing dependencies, whatever…). But, again, it’s more about aligning with IDEA features than a real problem.
IMHO, a possible implementation would be passing flags to the compiler indicating which annotations will define the nullability of platform types, and then, when IDEA invokes it, it simply passes all the defined annotations in settings. Then, instead of hardcoding the annotations classes in JvmAnnotationNames.kt, populate the lists with the compiler flag.
Implementation is not the issue here; the issue is adding compiler options that affect the semantics of the source code. We want to avoid adding such options as much as possible, and aligning with IDEA settings is not a goal here.