No issue at all is guaranteed to be fixed by the next release. There's no expectations that the deck of issues gets cleared when a new release is published, so conflating the two topics isn't accurate or helpful.

You'll have to explain why the master branch approach isn't ideal. The only argument I've seen hold up is that the community can pin their own crates around a specific release, so if you rely on a lot of third party crates, you benefit from more frequent releases. Given iced is still pre-1.0, I do not encourage people to rely on a lot of third party crates. Most of them also have permissive MIT licenses so you can always bring any one-off bit of code into your own crate and maintain attribution. I did that with the split widget from iced_aw, which was available in 0.12 and dropped by those maintainers when 0.13 came around. I've since made several tweaks to it to fit my specific use cases, so all in all I'm just better off vendoring it myself.

In fact, you also have no guarantee that third-party crates will (1) continue to update for future releases and (2) evolve their own APIs in the manner that you prefer. So if you're worried about being up-to-date and/or stability, again bringing the code into your crates is again the better choice—at the obvious cost of having to maintain it yourself, but such is the nature of software.

I do not know what you mean by "inspire the same level of trust". Or I think I do, but I do not think it's helpful language or an accurate framing. Are you a part of the iced community? I can't speak for everyone, but ISTM that most everyone trusts hecrj implicitly—and we all understand iced is a labor of love, not commercial and the fact that it is subject to his whims actually helps guide a specific vision forward, however long that may take. The ride has been great so far. The Pop!_OS team seems to agree.

Finally, about Dioxus specifically, I'll leave this informative video here https://www.youtube.com/watch?v=dKvFFf04clU

I watched this video when it first came out. Honestly, the video is right in what it was trying to say. That said, that video didn't change my mind on whether to build on Dioxus and it should not for someone either.

The choice of framework should not be dependent on who else is building on that framework. Ideally the factors that matter: 1) Why are you building a GUI app on rust? 2) Target platform/OS support? 3) Are you ok with custom styling methods? Would you prefer to use CSS? 4) Need for multi threading? 5) Publishing / bundling / signing app

I think the reason Dioxus cadence release is slow is that they realised so many things are missing with the rust gui ecosystem that they decided they needed to fix these while building the main product. Guess what, this basically slows down your main product cadence. Does rust need a sub second hot reloader? Yes. Does rust need a native html/CSS renderer? Also probably yes. Did the Dioxus team have to take it on given their size and all the things pending in building rust with html + css? Armchair observer me thinks not.

*Note that I am currently building an app with Dioxus, so I'm putting out my honest opinion, and not saying that you shouldn't use it.*