doitlater | Increase page loading speed | Awesome List library

Your analysis has missed the mark on more than one point:

•Bar is a struct. And therefore all instances should be stored on the stack

This is not true. A value type object can be stored on the stack, but not all value types are stored on the stack. See Eric Lippert's famous The Stack Is An Implementation Detail article.

In your example, the bar object is in fact not stored on the stack, because it's captured in the closure you pass to doItNow(). The compiler creates a hidden class where the bar object is stored, and this class is allocated on the heap. So the bar object itself is allocated on the heap as well.

•When the Task.Delay(100) is hit, that thread of execution is done, and the TPL is requested to execute fn() at a later time.

Actually, it's when the await is hit. Simply calling Task.Delay() does nothing more than create and start a new Task that will complete in 100 ms. It's not until the await is executed that the doItLater() method returns. Which is not the same as "that thread of execution" being "done". The thread continues (in your case, as far as calling Wait() on the Task object returned by the doItLater() method).

•bar is stored on the stack and by the time we access it in the closure, that frame that shouldn't exist.

Because you call Wait(), even if it were true that the bar object was stored on the stack, that stack frame would still be present when the continuation in doItLater() is executed and the fn() delegate invocation is executed. The Main() method can't return until the Wait() method completes, and that doesn't happen until the doItLater() task is entirely complete (including having invoked the fn delegate that was passed to it).

In other words, even if we ignore the other misconceptions you have, it's not even true that there'd be a problem in this case, because the bar object would still exist regardless.