Challenge 2: Ignoring the Warning — A Real Runtime Crash — Possible Solution
====================================================================

Program.cs:

static string? GetName(bool provideValue)
{
    return provideValue ? "Alice" : null;
}

static void Main()
{
    string? maybeNull = GetName(false);
    Console.WriteLine(maybeNull.Length);   // compiler WARNING here, but compiles anyway
}

Representative compiler warning (build still succeeds):

    Program.cs(9,32): warning CS8602: Dereference of a possibly null
    reference.

Representative runtime output when run:

    Unhandled exception. System.NullReferenceException: Object
    reference not set to an instance of an object.
       at Program.Main()

Explanation:
The compiler correctly flags maybeNull.Length as unsafe with warning
CS8602, since maybeNull's declared type (string?) genuinely allows
null and GetName(false) does return null here. Crucially, this
warning does NOT stop compilation -- the program builds successfully
regardless, and only fails at runtime, when Length is actually
accessed on the null reference, throwing NullReferenceException
exactly as it would have without nullable reference types enabled at
all.

WHY THIS WORKS AS AN ANSWER
------------------------------
This demonstrates the chapter's own central honesty point directly:
a real nullable-reference warning is ignored, the code still compiles
and runs, and it still crashes at runtime -- proving the warning is
advisory, not a guarantee, unlike Kotlin's equivalent compile-time
error.