ContentManager synchronous loading limits when streaming large textures in MonoGame

MonoGame's Content Pipeline compiles source assets into binary .xnb files that the runtime ContentManager loads through synchronous calls such as Content.Load<Texture2D>(). Because the default behavior blocks the calling thread until the asset is fully available, loading large textures during active gameplay can stall the main game loop.

When designing a scene that streams high-resolution art dynamically, the strict directory structure relative to Content.RootDirectory and the platform-specific build profiles add constraints on where and how assets are packaged. The unresolved decision is whether the framework provides a documented mechanism to load these compiled assets without blocking the render thread, or if developers must implement their own background loading wrapper around the existing ContentManager API.

Additionally, if multiple scenes share a subset of assets, the behavior of ContentManager disposal during scene transitions becomes uncertain: does unloading a scene-level ContentManager force reloads of shared assets, or is there a supported pattern for layered content managers that avoids redundant loads?

Specific questions:

1. Is there a documented non-blocking or asynchronous loading path in MonoGame's ContentManager for .xnb assets, or is synchronous loading the only supported runtime behavior?
2. What is the recommended pattern for disposing scene-specific ContentManager instances without forcing reloads of shared assets?
3. Does the Content Pipeline impose practical limits on asset size or count that would make runtime streaming inadvisable compared to pre-loading?