I've struggled to find a real reason to get into learning UWP. Without Windows phones it just isn't compelling to move from WPF. Especially, when you are talking about applications that require high information density.
I assume you're referring to the constructor for the command. The Execute() method for an ICommand doesn't return a value. It's considered to be, like event handlers, an acceptable place to use async void.
Since we're talking about pronunciations... It's "ternary" (turn-a-ree) not "tenary" (ten-a-ree). I believe Robert mentioned it being added to the language at version 6. However, it's been with C# since the beginning.
@SteveRichter: Because business uses it and desktop applications remain the best choice for targeting many aspects of the enterprise. I prefer desktop applications in other situations as well, but that can be debatable.
The length of the show should be whatever the length needs to be. Don't make it a certain length for an arbitrary reason. Make it 10, 20 or 30 minutes long, whatever the content dictates. Don't add filler or cut content to make it a certain length.
P.S. reCAPTCHA is fine; sure it's an annoyance, but it's unfortunately necessary.
One other point I wanted to make on the video is regarding sealed classes. In the video you indicate that a sealed class is a code smell. I strongly disagree with that sentiment as do others. For example, Jeffrey Richter wrote about it in his book CLR via C# when he said it should be the default for new classes.
There are run-time optimizations that are available for sealed classes according to the language specification 10.1.1.2; and more specifically with versioning a sealed class can be changed to unsealed later and not break compatibility and methods in a sealed concrete class can be called non-virtually.
That's not true. Although I'd argue that most Singletons are going to live for the lifetime of the AppDomain, it's possible that you may want to clean up before hand. Additionally, your Singleton may use system resources (especially unmanaged resources) that you want to be explicit about cleaning up. After all, there are no guarantees made that finalization (invocation of the destructor) will be invoked when the AppDomain is shutdown (more info).
I disagree with the assertion that you should implement IDisposable in what was seemingly inferred as all the time. IDisposable is a design pattern, not a classic pattern, but it's still a pattern. It should be used when the situation warrants it. Furthermore, a destructor should never be added unless absolutely necessary (see 18.104.22.168 in the language specification).