О сравнении объектов по значению — 6: Structure Equality Implementation

Имплементировать два IEquitable<T> это неправильное использование интерфейса. С чего это класс T должен реализовывать интерфейс для какого-то другого IFoo? Пусть даже для него есть удобный синтаксис в языке.

Нехорошо модифицировать параметры, которые приходят в конструктор. Если я создаю new Person("blabla", null, null) я рассчитываю, что LastName будет null, а не какой-нибудь "unknown". А потом словить баг, где я проверяю наличие фамилии (ну вдруг речь про африканца, у которого есть только имя), а у меня никогда это условие не прокает. Придется лезть в конструктор и видеть, что он подменяет то, что я хочу видеть. Так что у конструктора тут два варианта: либо сеттить все, что угодно, либо явно кидать исключение "Должна быть фамилия".

Хэшкод будет давать одинаковый хэш для "A", "B", null и "B", "A", null. В таком случае обычно делается умножение на константу.

Непонятно, зачем статический метод? Почему человек просто не может вызывать ==? Вот честно, я скорее вызову if (a == b) чем if (PersonStruct.Equals(a,b)). Это и короче (взгляд сразу цепляется за ==, а имя метода нужно парсить), и понятнее (я не припомню сходу структуры со статическими методами подобного рода во фреймворке). Короче, бесполезный метод.

О какой упаковке речь? От того, что вы для равенства создали новый алиас ничего собственно не поменялось.

Так же неясно, о какой магии речь. Там простой как валенок код "проверить наличие значения в обеих Nullable<T>, если их нет, то тут все понятно, если есть, то вызвать их собственный Equals":

        public override bool Equals(object other) {
            if (!hasValue) return other == null;
            if (other == null) return false;
            return value.Equals(other);
        }

На мой взгляд корректная реализация должна выглядеть как-то так:

public struct PersonStruct : IEquatable<PersonStruct>
{
    public string FirstName { get; }

    public string LastName { get; }

    public DateTime? BirthDate { get; }

    public PersonStruct(string firstName, string lastName, DateTime? birthDate)
    {
        FirstName = firstName;
        LastName = lastName;
        BirthDate = birthDate;
    }

    public bool Equals(PersonStruct other) => FirstName == other.FirstName && LastName == other.LastName && BirthDate.Equals(other.BirthDate);

    public override bool Equals(object obj)
    {
        if (ReferenceEquals(null, obj)) return false;
        return obj is PersonStruct && Equals((PersonStruct) obj);
    }

    public override int GetHashCode()
    {
        unchecked
        {
            var hashCode = (FirstName?.GetHashCode()).GetValueOrDefault();
            hashCode = (hashCode * 397) ^ (LastName?.GetHashCode()).GetValueOrDefault();
            hashCode = (hashCode * 397) ^ BirthDate.GetHashCode();
            return hashCode;
        }
    }
}

Меньше кода — меньше ошибок. Всё, что нужно для структуры и сравнения тут есть. До Nullable нам не должно быть никакого дела, это у майкрософта должна голова болеть, чтобы правильно сравнить два упакованных объекта (и поверьте, они делают это хорошо). У вас много ссылок на документацию, но при этом я ни разу не видел в требованиях к структурам реализовывать дополнительные статические метод с nullable или имплементировать IEquitable<Nullable<T>>

дубль.