Gino Valente

> I think we can modify the methods for `Reflect::set` and `PartialReflect::try_apply` for `ReflectBox` to first check if the underlying type is the same or different, then decide whether to...

> Given `foo1` and `foo2` having the same type I would expect `apply` to never fail, and instead it does with: > > ``` > called `Result::unwrap()` on an `Err`...

> > looking at the PR description, i'm very confident all of the mentioned caveats can be solved: > > > > 1. `FromReflect` > > > > we can...

> Alright, thanks to both @MrGVSV and @soqb for addressing my concerns :) If the limitations aren't any worse, then I'm fine to defer to you about maintenance burden. `ToReflect`...

> > Something like this (I have not tested whether this compiles) > > could easily become: > > ``` > s.field_mut("boxed").unwrap().set(replacement); > ``` > > NB: i'm not sure...

I may have a solution for this actually 🤔 **Update:** I mentioned my idea on [Discord](https://discord.com/channels/691052431525675048/1002362493634629796/1275272307119751269), but I'm having a lot of concern over the complexity of the solution—both in...

FYI I just put up a new PR that uses a different approach that I think is a bit cleaner (at least from an end-user perspective) and will be easier...

> My take: IMO the crates with no `crates.io` release should never have been added to Bevy Assets in the first place. Personally I think it's okay. Some crates are...

It might be useful too if crates automatically tracked when they were last published or when a commit was last pushed.

> @MrGVSV wouldn't that already be handled by sorting by latest supported Bevy version? I think going beyond that would be a bit hard to analyze, since many crates are...