i don't love this. alternatively, above this, we call solution.AddProject. if we're comfortable with the idea, i could make it so that this logic automatically happens in .Add/.RemoveProject so that our in-memory forks reread this host data.

It feels OOGy to me though. because that means you might have a solution snapshot with one set of options, and you fork it,a nd now the options are different due to the underlying host. it feels like we don't want that, and options in forked snapshots should not change unless explicit. instead, only when the host updates .CurrentSolution should it change.

So this, while oogy, feels the cleanest to me.

Why not fork the solution with the project projectToAddTo.Solution further to add the options?
Then you could just call InitializeAnalyzerFallbackOptions and we wouldn't need ComputeFinalFallbackAnalyzerOptions

oops. that's just a mistake. though, wehen you say "to add the options", how do you envision computing which options are needed?

i suppose i could just do:

            var provider = oldSolution.Services.GetRequiredService<IFallbackAnalyzerConfigOptionsProvider>();
            newFallbackOptions = newFallbackOptions.Add(language, provider.GetOptions(language));

though the benefit of having and calling into the helper is that it works regardless of the state the workspace is in when FormatDocumentCreatedFromTemplateAsync is called.

This does the same thing now, no?

private static Solution InitializeAnalyzerFallbackOptions(Solution oldSolution, Solution newSolution)
        => newSolution.WithFallbackAnalyzerOptions(ComputeFinalFallbackAnalyzerOptions(oldSolution, newSolution));

Services is 'HostWorkspaceServices', which is the exact same backing store for Solution.Services. So we dno't need to access this.Services and can instead make this a static method that only depends on OldSolution/NewSolution. To make it clearer what this is doing, i had this just return the final desired 'fallback analyzer options', and it's up to the caller to decide what to do with it.

Note: as a static method on Workspace, this could just move to an instance/static method on Solution instead, which seems to be the more appropriate location. I'm open to thoughts here.