Until Zig has a good story for use after free, I wouldn't be considering it.
Regarding C#, there was some research work at MSR for improving escape analysis and IDispose usage via lifetime analysis, but seems to never have moved beyond proof of concept.
By the way, Midori internal presentation from 2013 is doing the rounds on twittersphere.
I don't think there was any work on escape analysis in current .NET related to Midori, at the very least not in public. However, there has been separate research and support for object escape analysis unrelated to this.
At the time, the results were very unpromising given compiler throughput impact: there were very few objects that were not escaping due to inlining limitations and (relatively) rudimentary approach to EA. In addition, there obviously was no impact on performance sensitive code that just used structs instead that are not reliant on fragile optimizations like this one.
Here, I would like to add a personal note that .NET teams are exposed to a much more well-behaved code and there existed (and still exists to an extent) bias that overlooks the nastiest and worst codebases that, no matter their issues and unnecessary allocation on every step, are an important optimization target. I think today there is a good degree of awareness and understanding of this bias, which drives further compiler improvements.
Back to EA. After initial research was done, the relevant code was merged into JIT - the feature was added around .NET 5 but remained disabled by default. Later on, it was occasionally in a broken state and generally not well validated against, given nothing used it besides compiler tests.
This, however, has changed in .NET 9. In order to understand why we first have to consider what were the changes in .NET's compiler in the previous versions.
Before .NET 7 and 8, JIT had nice but limited capability to perform something Java calls "scalar replacement" except for structs, the .NET name for this is "struct promotion". This feature "promotes" constituent struct fields to individual local values which are then stored in CPU registers or individual stack locations instead of "together" and being copied every time. This also included other common cases like treating single-field structs as an underlying field (making such wrappers effectively free). At the time, this optimization was great but nevertheless limited - there were restrictions on the amount of fields which could have been "promoted" and "enregistered" (up to 4 I believe?) as well as the depth - the quality of compiled code could easily regress if the target of promotion was nested within another struct, etc etc.
In order to address this, a new handling of struct promotion was introduced - "physical promotion": https://github.com/dotnet/runtime/issues/76928. This did away with the limitations of the past and enabled significantly better[1] handling of structs, allowing them to be optimized away, promoted without depth and count restrictions, propagate constants and assertions through struct fields, CSE more expressions on struct and more. This was a significant overhaul which pushed .NET's compiler output quality concerning structs way closer to the kind of behavior you would usually expect from GCC and LLVM.
At this point, I think you have an idea where this is leading to. Come in https://github.com/dotnet/runtime/pull/102808, an unrelated change which enabled the compiler to reason about propagation of addresses (object references, byref and unmanaged pointers) through struct fields. However, the importance of this change is that Steve (hez2010) noticed[0] that it may have closed the critical gap that previously prevented generalized optimizations enabling optimal struct handling from being applied to objects allocated on the stack. Once it was merged, it made the simpler scenarios EA was working for to produce the same optimal codegen you would see from structs as of .NET 8.
This and related discussions prompted further work on analyzing the most common unescaped allocation patterns and resulted in https://github.com/dotnet/runtime/pull/103361 by Andy Ayers. Once it was merged, it extended supported cases by previously limited EA capability, tuned inlining heuristics to make it light up more often and proved that the way it was handled as of the change was noticeably more profitable. It was subsequently enabled for NativeAOT and R2R as well: https://github.com/dotnet/runtime/pull/104411
As a result, .NET 9 will come with improved escape analysis capability, now enabled by default. It is still fairly limited but nonetheless an another change that incrementally adds to the nice "free" performance improvements everyone has grown to expect from bumping up a TFM version with each release for the last 7 years or so.
I don't claim this timeline/sequence of events is perfectly accurate but I hope it sheds light on how and why this optimization has been evolving in .NET so far.
Uff what a great reply, many thanks for the overview of ongoing EA efforts.
I was talking about this kind of research papers, there was one also about linear/affine types in a C# extension, similar to Spec#, System C# and others, but I can't get the title right to find it.
"Uniqueness and Reference Immutability for Safe Parallelism"
Regarding C#, there was some research work at MSR for improving escape analysis and IDispose usage via lifetime analysis, but seems to never have moved beyond proof of concept.
By the way, Midori internal presentation from 2013 is doing the rounds on twittersphere.