SpriteBatch and GraphicsDevice: Impact of SpriteSortMode on GPU State Changes

MonoGame uses the SpriteBatch class to interface with the GraphicsDevice, employing a deferred rendering system to minimize the overhead of GPU state changes. The efficiency of this pipeline depends heavily on the SpriteSortMode selected during the Begin() call.

When utilizing SpriteSortMode.Deferred, the framework batches draw calls until End() is invoked. However, the interaction between sorting modes and frequent changes to BlendState or SamplerState can lead to unintended draw call flushing, potentially negating the performance benefits of batching.

Given these constraints, how does the framework handle the internal flush mechanism when SpriteSortMode.Texture is used in conjunction with varying BlendState requirements for different sprites within the same batch? Does the GraphicsDevice force a state change and a new draw call for every blend state variation regardless of texture grouping?