There are two overloads of Match in ReferenceTypeAssertions

public AndConstraint<TAssertions> Match(Expression<Func<TSubject, bool>> predicate, string because = "", params object[] becauseArgs);
public AndConstraint<TAssertions> Match<T>(Expression<Func<T, bool>> predicate, string because = "", params object[] becauseArgs) where T : TSubject;

You probably just need to specify the type to hit the desired overload.

new MyClass().Should().Match<MyClass>(e => e.MyProperty == 42);

@georgiosd Does this answer your question?

Hey, sorry that I didn't follow up. It does, but explicitly defining the type in Match<T> seems very tedious.

Wondering how this hasn't come up before! Maybe I'm somehow an edge case :)

It boils down to the difficulty of designing a library based on extension methods.
That means we rely deeply on overload resolution.
Currently Match() maps to Match<TSubject>() where TSubject is a generic type parameter of ReferenceTypeAssertions<TSubject>.
For your custom class, Should() creates an instance of ObjectAssertions which inherits from ReferenceTypeAssertions<object>.
This means that o.Should().Match() maps to o.Should().Match<object>().

If we add GenericObjectAssertions<T> : ReferenceTypeAssertions<T> and the corresponding public static GenericObjectAssertions<T> Should<T>(this T actualValue), many types will resolve Should() to that instead of the desired one.
E.g. IEnumerable, which should use NonGenericCollectionAssertions is now picked up by GenericObjectAssertions.

Ah, that makes sense. Because there's no constraint that could enforce non-IEnumerables.

What if there was a method in ObjectAssertions that would specialize it? Like As<T> but only for this purpose?

A specialization as in the existing Match<T>() assertion?

If you mean something like

o.Should().Specialize<Myclass>().Should().Match()

then I prefer the current (and shorter)

o.Should().Should().Match<MyClass>()

One that will trickle down the chain:

Should().As<T>().Match(...).Match(...)

or even

Should<T>().Match(...).Match(...)

One could maybe do something like

class GenericObjectAssertions<T> : ReferenceTypeAssertions<T, GenericObjectAssertions<T>>
{
    public GenericObjectAssertions(object value)
    {
        if (value is null)
        {
            Subject = default(T);
        }
        else if (value is T castedValue)
        {
            Subject = castedValue;
        }
        else
        {
            throw new InvalidCastException();
        }
    }
}

GenericObjectAssertions<T> Should<T>(this object actualValue)
{
    return new GenericObjectAssertions<T>(actualValue);
}

That would be beneficial for

ReferenceTypeAssertions.Match(Expression<Func<TSubject, bool>> predicate, ...)

as the right TSubject would be picked up

but worse(?) for

ReferenceTypeAssertions.BeSameAs(TSubject expected, ...)
ReferenceTypeAssertions.NotBeSameAs(TSubject unexpected, ...)

as those are then "restricted" to TSubject instead of object.

Yes, I see.

But if it's a secondary method like As<T> then it shouldn't be a problem right?

Another workaround is to define a your own assertion class that derives from ReferenceTypeAssertions.
This of course gets tedious if you rely on Match for many different types.

private class MyClassAssertions : ReferenceTypeAssertions<MyClass, MyClassAssertions>
{
    public MyClassAssertions(MyClass subject)
        : base(subject)
    {
    }

    protected override string Identifier => nameof(MyClass);
}

public static Extensions
{
    public static MyClassAssertions Should(this MyClass myClass) =>
        new MyClassAssertions(myClass);
}