Stephen Toub

> needless to say it also hinges on numerous other concepts All true. To me this highlights that a solution for ConfigureAwait could naturally fall out of solving all those...

>method to take precedence is still a breaking change, because that method could exist today, and doesn't take precendence! Yeah, was hoping you wouldn't notice that ;) That's actually from...

> The builder can remove or replace the synchronization context for the operation before the awaiter is created. Not without changing other semantics the method may be relying on. And...

> The attribute approach just seems cleaner to me Which attribute approach? I've yet to see one that's actually viable.

> I don't see any problems with the viability of a ConfigureAwaitAttribute(bool) That applies to what types?

> presence of a using statement using for what? There's no namespace in my example. It's no different from the attribute in that regard: either you include the code or...

> If it's put in the global namespace, then if someone imported it into a nuget package it would effect every package that consumes that package wouldn't it? Why would...

> There has to be, otherwise you screw up everyone's notion of await and you can't have different custom versions within a project. There doesn't have to be. You can...

This issue covered three approved APIs: ```C# Path.GetTempFileName(); File.CreateTempFile(string? prefix = null, string? suffix = null); Directory.CreateTempSubdirectory(string? prefix = null); ``` The first and third were implemented, and there seem...

core and framework are the two I've personally cared about.