In an application that wants to handle WM_CLOSE in a special way (like continuing to run in the background), the event handling that the WindowsLifecycleManager does isn't optimal: it prevents the custom WM_CLOSE handler from running, since it always handles the event, preventing the event from propagating.

Perhaps the event should never be handled by the WindowsLifecycleManager, and if the app allows the exit request, then it will exit, closing the window anyhow, and aborting the window close itself should be handled by the (as yet nonexistent) windowing API.

If that's not the solution, then perhaps this is what we need to do:

1. Windows sends WM_CLOSE message
2. Flutter eats the Windows message and notifies the framework
3. If the framework cancels the exit, Flutter creates a new WM_CLOSE message
4. This new WM_CLOSE message is ignored by Flutter, allowing the app to use custom logic

In any case, we need to evaluate how to enable this scenario.

Related internal issue: b/275565297