The initial Windows embedding landed API-compatible with the GLFW embedding, which is very much not the final form we want the API to take. I'm sure we'll need to discuss and iterate, but a few initial things that I know we'll want (unless they end up being infeasible for some reason):

• The API should expose direct access to the window handle (which among other things should eliminate the need for specialized wrappers for window size, window title, etc.)
• The API should allow embedding in a window containing other native controls if desired.
• The runloop should be incremental, not all-or-nothing—if we even need a runloop API; I'm not familiar with windows runloop APIs so I'm not sure if we could do something more like macOS where it's all handled for us and we post engine events into a standard OS runloop.
• There should be a clear division, but with shared objects, between headless mode and view mode, as with FlutterEngine/FlutterViewController on iOS/macOS.