Thanks, I'll check soon.

Thanks for reviewing. And ya, sorry about the size of the PR. I too am relying on tests overall to know that we're moving forward. And yes, we surely need to add more tests for better coverage as we go.

Regarding your generics question, I still like my proposal that you linked to. I don't think it's fully implemented yet. Generics is a huge space for this and I think it'll have to come incrementally.
But regarding the particular code snippets you shared, I don't understand why you would apply [MessagePackFormatter] attributes to a formatter type. Isn't that attribute meant to be applied to a data type in order to help a resolver find the formatter?

The current changes give users the impression that custom formatters are automatically included.

That's exactly right. The only case where MessagePackFormatterAttribute is required after this change would be to bring in a formatter that is declared in some other assembly than the data type itself.

I understand. No worries.

I don't understand why you would apply [MessagePackFormatter] attributes to a formatter type.

Oh, sorry, I meant to provide the following example but omitted it.

[MessagePackObject]
public class MyClass
{
    [Key(0)]
    [MessagePackFormatter(typeof(MyCustomFormatter<int>))]
    public int MyProperty { get; set; }
}

public class MyCustomFormatter<T> : IMessagePackFormatter<T>
{
    //...snip
}

I think that example will do the right thing. Specifically, the 'open generic' formatter will get into the resolver as an open generic. Then specific closed generic types that are statically discoverable also make it into the resolver specifically, thus avoiding Activator.CreateInstance and allowing AOT compilers to know which formatter closed generic types to compile native code for.