Support for Custom render context

I want to use Stride as a 3D renderer for a cross platform project where the render window is integrated in the Avalonia UI.
Now both Stride and Avalonia, theoretically, would support this quite nicely but the issue appears with extending the Stride engine with a new rendering context (this means custom GameContext, GamePlatform, GameForm and GameWindow) which would be based on Avalonia native controls (rather then, for WinForms, based on System.Windows.Forms.Control). This is not a complicated extension as it would be, more or less, equal in implementation with the current WinForms.

The problem is that when using the Stride nuget packages (or the old Xenko ones), consumers of these packages are not allowed to provide custom instances to these classes because:

• GamePlatforms are created in a static internal method and based on an enumeration so there is no way to provide a custom implementation here;
• GamePlatform itself is marked as internal which means we couldn't inherit from it;
• GameWindow contains internal abstract methods which cannot be overloaded;
• There are various other properties or methods marked as internal that might be required in such an implementation but I don't currently have an exhaustive list for those.

Is there a design limitation for why a consumer of these assemblies couldn't provide custom classes for rendering concepts? From what I can tell, the rest of the code is neatly abstracted and should work regardless of what implementations we might have there.

Exposing the internal members outside the assembly and introducing a new overridable factory pattern for creating game platforms would allow one to fully implement these concepts in separate assemblies without having the need to modify the internal Stride code.

Of course, this would not have any impact on the GameEngine itself but would allow Xenko to be embedded in any kind of contexts.

Lastly, if there are no design limitations with my proposals or other issues I may not notice now, would a merge request be accepted? I can pretty easily fork the repo and maintain my own implementation of it but I feel it would be much better, if there are no downsides, to have it contained in the main repository.

Start by tracing how the static internal factory creates GamePlatform instances and review the accessibility of GameContext, GamePlatform, GameForm, and GameWindow. Define the public extension points and factory behavior needed for consumers to provide Avalonia-backed implementations without modifying Stride, then validate that an external assembly can implement the complete rendering context.