daxpedda

That does sound fine for me. However, I think I would prefer to guide users towards `spawn()` if at all possible for non-crossplatform behavior. Do you have a use-case specifically...

> I'm not using `run()`, I'm using `spawn_app()`. I'm still not seeing a `spawn()` type API that let's me run multiple `ApplicationHandler`s in parallel. If I'm overlooking a solution that...

I'm thinking that the best implementation might be to make `spawn_app()` entirely ignore recreation flags and such instead of resetting it. --- I was surprised that the current behavior was...

> I'm not sure how handling `CloseRequested` is at odds with parallel `EventLoop`s? I expect that multiple things on a given webpage could be registering to block navigating away/closing, including...

> Isn't it fine if it's a _specific backend_ behavior that you should generally not rely upon, but just how the current backend may work? it's not a `winit-core` API...

> if in the future you would be able to achieve the desired functionality with the single event loop then I don't see an issue. OPs motivation is already achievable...

Check https://github.com/rust-windowing/winit/pull/4276#issuecomment-2954264293 for the use-case. But indeed, event loops doesn't support being run in parallel. But there is no use-case for running the event loop in parallel except for simpler...

> To not reimplement the whole `serde` in this crate, you can just emit the corresponding `#[serde(bounds)]` and hand off the rest to the upstream derive macro We talked about...

I'm in favor of sticking with the same strategy we applied to `Zeroize`. So we only accept `Deserialize` and `Serialize`. By default we use the path `serrde::De/Serialize`, but users can...

I looked into this and AFAICT this isn't something `derive-where` can handle. The issue is that we need to append attributes to the item, which the internal derive macro is...