In v1, when a user instantiates a TestContext (v2 this will be named BunitContext), it creates a shared TestRenderer (v2 this will be BunitRenderer), that is used with every call to TestContext.Render(). For v2, I still want a shared BunitContext, but each call to RenderAsync will get its own BunitRenderer instance.

Looking at existing test suites, by far most tests will just have a single call to TestContext.Render() so I don't expect that the overhead of creating a renderer per Render call will have a perf impact for most.

The primary motivation is that a renderer will share a service provider with all components it renders, and that does have some impact on a few things, such as supporting "shallow rendering". My thinking is that when RenderAsync is called on a BunitContext, it creates a new service scope from the service provider it has, such that singleton services are shared between render calls, but scoped services are not.

If users still want to render multiple top-level components, they should just wrap them in a RenderFragment, e.g.:

RenderAsync(
  @<text>
    <FirstComponent />
    <SecondComponent />
  </text>);

Another reason to make this switch is that, as far as I can tell, the various Blazor renderer Microsoft has created does this. So while there does not seem to be any negative impact currently, it may be an assumption the Blazor team will leverage in the future.