Let's address these claims one by one:

> Except plenty of people, including Microsoft own products, are still stuck in .NET Framework.

Would this necessitate evaluation of Java 8's (and corresponding JVM) viability against modern languages and platforms too?

> Additionally plenty of business are only adopting LTS versions.

.NET 6 is an LTS version and so is 8.

> Then we have big names like Sitecore, that decided it was time to move on, and all their major acquisition are based on Java and JS/TS products.

When a particular (medium size) company picks a technology, it has no impact on its viability because it does not retroactively alter its advantages or disadvantages unless the company invests in the ecosystem (which Sitecore does not, but then again, this is a nonsensical argument)

> The GUI civil war isn't helping the community.

It is true that situation with GUI frameworks in C# is far from ideal, it is being worked on, but there is no catching up to JS/TS front-ends written even for desktop applications. For all it's worth, Xamarin continues to be loved by enterprise, and, maybe, one day MAUI will be made successful despite extremely rough start (I'm not holding my breath though).

> The .NET team was grilled on twitter due to the way the last Technetpower benchmark was conducted.

Almost all top participants in Techempower pretty much do some degree of benchmark gaming. However, this does not, by itself, indicate the deficiency of the language or the runtime (if it did, we'd have all popular languages classified as deficient). In fact, asm emitted for C# trades blows with the likes emitted for C++. In many-core gRPC scenarios, Kotlin is at a similar level of performance, but as a language itself does not allow going as low-level as C# does (it effectively competes with both Go and Kotlin, offering a different set of tradeoffs).

> While F# keeps being neglected, VB is stable, and CLR changes to mean C# Language Runtime, JVM now enjoys Scala, Kotlin and Clojure.

Can you expand on this? F# ecosystem does see less developer activity than C# from the language standpoint. However, it receives all the same performance and shared library improvements, and .NET does not introduce changes which break F#. Similar to Sitecore statement, VM being targeted by a multitude of languages does not make it automatically better (or worse) nor is a proxy for its performance characteristics. It is necessary to assess a technology at its face value.

> NativeAOT is still not going to be fully done for .NET 8, and apparently it will require minimal APIs to be usable, hello rewrites, yet again.

NativeAOT was "done" for .NET 7 for win-x64, linux-x64 and linux-arm64 targets, with osx-arm64 (it was not a goal for .NET 7) pull-request narrowly missing the feature snap window, therefore getting postponed to .NET 8. It also appears the argument might stem from conclusions learned from GraalVM AOT which do not apply to .NET. Unless used in a serverless function, back-end .NET deployments are best served by simply staying with JIT, which would offer higher sustained throughput. Native AOT is first and foremost designed for completely different scenarios.

> Still no roadmap for GUI support on Native AOT, and then there is the recent joke that VSCode MAUI plugin doesn't do Linux anyway, only Android, when on Linux.

All code targeting .NET historically relied on features by definition incompatible with true AOT (like in C++). It is a non-trivial effort to address issues of specific frameworks, which is being done, and the language itself adopts newer features (source generation. unsafe accessors, linker/trimmer improvements) to make it easier.

As for Linux, please give Avalonia a try.