Heads up: .NET 11 is still in preview, and everything below is based on Preview 6. Details could shift before the final release, so treat this as a sneak peek rather than a spec sheet.

The .NET 11 previews have been quietly stacking up some genuinely exciting improvements, and two of them stand out for how much they change the day-to-day experience of writing code. One lives deep in the runtime; the other lands right in the C# language you type every day. Let’s dig in.

1. Runtime Async: async that finally behaves in a debugger

If you’ve ever stared at a stack trace from a heavily-asynchronous production incident, you know the pain. Instead of a clean chain showing which method called which, you get a mess of compiler-generated state machine types—MoveNext() frames, AsyncMethodBuilder plumbing, and gaps where your actual logic used to be. Piecing together “what actually happened” becomes detective work.

Historically this is because async/await was handled almost entirely by the C# compiler. It rewrote your method into a state machine at compile time, and the runtime just saw the resulting machinery—not your original intent. Great for portability, rough for diagnostics.

Runtime Async moves a big chunk of that work down into the runtime itself. The payoff is threefold:

• Cleaner stack traces. Async call chains look a lot more like the code you wrote, so tracing a failure through several awaits stops being a puzzle.
• Lower overhead. Handling async at the runtime level means less generated boilerplate and fewer allocations in hot async paths.
• Less painful debugging. Stepping through async code and reading exception traces just gets more predictable.

Why does the stack trace bit matter so much? Because when something breaks at 2 a.m. in production, the stack trace is often all you’ve got. If it reads like an honest map of your call chain instead of a wall of compiler artifacts, you find the root cause in minutes instead of hours. That’s not a nice-to-have—that’s real time back in your life.

There’s a strong signal Microsoft is confident here: as of recent previews, Runtime Async no longer requires the EnablePreviewFeatures flag for projects targeting net11.0, and the runtime libraries themselves now ship compiled with runtime-async turned on. When the platform’s own libraries are built on it, that tells you it’s graduating from “experiment” to “foundation.”

2. C# 15: extension indexers and built-in union types

The language side of .NET 11 brings two additions that quietly kill a lot of boilerplate.

Extension indexers

.NET 10 kicked off the “extension members” work, letting you add methods and properties to existing types through extension blocks. But it left a gap: you couldn’t add an indexer—the this[...] syntax—to a type you don’t own.

C# 15 closes that gap. Now you can attach indexer syntax to an existing type from an extension block. In plain terms: if you’ve got some type that logically “should” support thing[key] access but the original author never added it, you can bolt that ergonomic syntax on yourself—no wrapper class, no awkward GetValue(key) helper method sitting off to the side.

It’s a small feature with an outsized effect on how natural your APIs feel to consume. Extension members are now a coherent set—methods, properties, and indexers—instead of a half-finished feature.

Built-in union types

How many times have you needed to express “this value is one of a few possible types”? Maybe a result that’s either a Success or an Error, or a parser node that could be one of several shapes. Until now, C# made you hand-roll it: base classes with subtypes, clever enums paired with nullable fields, or a full discriminated-union library. It worked, but it was verbose and easy to get subtly wrong.

C# 15 adds built-in union support types, giving the language a native way to say “this is one of these options.” The benefits are immediate:

• Less boilerplate. No more scaffolding a class hierarchy just to model a few alternatives.
• More expressive intent. The type itself declares the possibilities, so readers (and the compiler) know exactly what they’re dealing with.
• Safer handling. Modeling “one of several” as a first-class concept plays much nicer with pattern matching than the improvised approaches did.

Together, these two additions push C# further toward code that says what you mean with less ceremony—which is exactly the direction most of us want the language to go.

The through-line

What’s nice about this release is that both headliners share a theme: reducing friction. Runtime Async makes the code you already wrote easier to debug and cheaper to run. The C# 15 features let you express your intent with less scaffolding. Neither is a flashy gimmick—they’re the kind of improvements you feel every day.

If you like poking at things early, grab the .NET 11 preview SDK and take Runtime Async and the new C# 15 features for a spin. Just remember it’s still preview software (this was written against Preview 6), so expect some churn before general availability, which is currently expected in November 2026. Have fun experimenting.