@AArnott
Currently, the behavior of MessagePack.SourceGenerator is more like the mpc implementation that existed before.
However, there are a few areas where it is unnatural and unreasonable to consider it as a Source Generator.

As a solution, how about adding attributes to the partial class in the same way as the Source Generator of System.Text.Json?

namespace MyApi; // use this namespace

[MessagePackResolver(/* new attribute */ usesMapMode: true/* options here */)]
public /* use this accessibility */ partial class FooResolver/* use this name */;

Additionally, the generation of formatters will only be executed when the above Resolver exists.
When referencing the Source Generator, reacting to attributes other than just the Source Generator and initiating generation by default seemed a bit aggressive in behavior.

The AdditionalText in the config was quite inconvenient to use.
It would be better to accomplish as much as possible using attributes.

The public, name, and namespaces for the resolver are unnecessary.
usesMapMode and customFormattedTypes (which I think should be renamed) seem appropriate as parameters for the MessagePackResolverAttribute.
I wonder if formatters can also be parameterized.

This approach should be more user-friendly.
In other words, loading configs through AdditionalFiles will be completely deprecated.

Since there won't be any impact as long as it's not generated forcibly,
it might be okay to include references to the Source Generator (and maybe Analyzer?) in the Annotations,
similar to how Microsoft.Extensions.Logging.Abstractions does.
https://github.com/dotnet/runtime/blob/main/src/libraries/Microsoft.Extensions.Logging.Abstractions/src/Microsoft.Extensions.Logging.Abstractions.csproj#L44-L54"

Off-topic:
Would you consider adding a FUNDING.yml to GitHub?