I don't know which developers you talked to. Honestly I should just flag this reply probably.
It's nothing surprising in .NET land. If you target netstandard2.0 the library will work on any version from .NET Framework 4.6.1 and upwards. For many newer features there are compat and polyfill pacakges too - that's one of the strengths to be able to use them even on the older targets.
All newer targets are forward compatible anyway. Wherever the notion of otherwise comes from it is likely a misunderstanding or trolling.
You can't make a serious argument when comparing baseline experience where .NET confidently places next to Cargo and Golang's user experience with the level of productivity it provides for setting up and managing projects and dependencies, building them and distributing them. JVM ecosystem still does not offer capability to properly and easily package the applications into a single binary except using very restrictive GraalVMs Native Image which does not have as wide ecosystem support as NativeAOT enjoys, and where it does not work .NET still gives you the ability to bundle managed assemblies into an executable together with runtime, apply trimming and get relatively compact result.
Contrary to Native AOT, Java tools have always found a way to deal with reflection, instead of asking the ecosystem to rewrite their libraries.
Yes there are AOT friendly frameworks, however JVM agents have also provided a way to gather the necessary data for a AOT compilation, since the Exelcisor JET days.
It's nothing surprising in .NET land. If you target netstandard2.0 the library will work on any version from .NET Framework 4.6.1 and upwards. For many newer features there are compat and polyfill pacakges too - that's one of the strengths to be able to use them even on the older targets.
All newer targets are forward compatible anyway. Wherever the notion of otherwise comes from it is likely a misunderstanding or trolling.
You can't make a serious argument when comparing baseline experience where .NET confidently places next to Cargo and Golang's user experience with the level of productivity it provides for setting up and managing projects and dependencies, building them and distributing them. JVM ecosystem still does not offer capability to properly and easily package the applications into a single binary except using very restrictive GraalVMs Native Image which does not have as wide ecosystem support as NativeAOT enjoys, and where it does not work .NET still gives you the ability to bundle managed assemblies into an executable together with runtime, apply trimming and get relatively compact result.