When a developer at $COMPANY encountered sporadic null reference exceptions in a service, the culprit defied conventional logic. A RequestContext property, demonstrably initialized early in each request and never reassigned, appeared null at critical moments – despite logs confirming its existence elsewhere. The root cause lay hidden in C#'s handling of partial classes and explicit interface implementations.

// Main Controller File
public partial class Controller : IController
{
    public RequestContext RequestContext { get; set; }
}

// Separate Helper File (added later)
public partial class Controller : IController
{
    RequestContext IController.RequestContext { get; set; }
}

This accidental duplication created two distinct properties:
1. The implicit RequestContext (accessible when typed as Controller)
2. The explicit interface property IController.RequestContext (accessible when typed as IController).

Initialization code setting controller.RequestContext (where controller is IController) populated only the explicit interface property. Methods accepting Controller or using this.RequestContext accessed the separate, uninitialized implicit property:

public void Test()
{
    Test1(this); // True (uses IController.RequestContext)
    Test2(this); // False (uses Controller.RequestContext)
    Console.WriteLine(this.RequestContext != null); // False
}

public void Test1(IController controller) => Console.WriteLine(controller.RequestContext != null);
public void Test2(Controller controller) => Console.WriteLine(controller.RequestContext != null);

This explained the 'phantom' nulls: changing the variable's compile-time type altered which property resolved.

A second, equally insidious bug emerged from default parameter mismatches in interface implementations:

// Interface
public interface IController
{
    void ProcessRequest(bool useRetries = true);
}

// Implementation
public partial class Controller : IController
{
    public void ProcessRequest(bool validate = false) 
    { 
        Console.WriteLine("Validate: " + validate); 
    }
}

Calling ProcessRequest() yielded different behaviors:

this.ProcessRequest(); // Output: Validate: False (uses implementation)
((IController)this).ProcessRequest(); // Output: Validate: True (uses interface default!)

The compiler allowed differing default values and parameter names between interface and implementation, creating silent behavioral splits based on the reference type.

These cases highlight critical, often overlooked sharp edges in C#:
1. Partial Class Pitfalls: Combining partial definitions risks property/name collisions, especially with interfaces.
2. Explicit Interface Ambiguity: Explicit implementations create 'hidden' properties decoupled from the class's own members.
3. Default Parameter Decoupling: Default values bind to the reference type at the call site, not the concrete implementation.

Prevention demands vigilance: rigorous code reviews for partial class changes, avoiding explicit interface properties unless essential, and ensuring default parameter consistency across interfaces and implementations. These 'ridiculous' bugs underscore how subtle language features, compounded by large refactors, can breed maddening, logic-defying defects.

Source content derived from Brandon Dong's debugging chronicle at brandondong.github.io.