The particular complaint mentioned in the article is Java <=> Mono transitions in Xamarin.Forms and if your focus is on Desktop that's not a concern on any of t

The particular complaint mentioned in the article is Java <=> Mono transitions in Xamarin.Forms and if your focus is on Desktop that's not a concern on any of the desktop platforms. .NET has long been rock solid in C/C++ <=> .NET transitions and WinRT <=> .NET transitions. (System.Windows.Forms does a ton of it and .NET 5 seems to have the expected performance from all those transitions.) The new interesting transition that it is still too early days to tell how well it will perform is the new .NET approach to Objective-C <=> .NET transitions/projections (which is more like the modern WinRT projection techniques) that is also different from the Objective-C <=> Mono transitions in Xamarin.Forms. (Though the article points out that the Objective-C <=> Mono transitions were fine and the new .NET approach on paper should be even better.) Also, from what I was reading, a modest version of the architecture change that the article was lamenting needed to happen to reduce Java <=> Mono transitions in Xamarin.Forms is supposedly happening in MAUI and they were trying to reduce the surface of "managed Renderer" code that transitioned in/out of OS level services. I don't know if what they are doing would be enough to satisfy the article's writer, but it apparently has been something on their radar.