irate

> Does this fully solve #1658? Not quite, #1658 mentions a join of two queries that produces a new `Query` which I do think is possible, but not for me...

Converting to draft because I'd like to base this on #5170 which will fix the unsoundness instead. I'll rework this and split out the changes to `iter_many`.

Is there really a need to worry about this on `main`? I would expect this to affect people using bevy from `crates.io` the most and I don't see a downside...

`many_iter` and `many_for_each_mut` essentially amount to a bunch of `Query::get`'s with slightly reduced overhead. Since `Query::get` is `O(1)` the complexity should be `O(n)` where `n` is the number of entities...

That should definitely be done eventually, but I don't think that should block merging this.

Bevy's `main` branch now has a [`scale`](https://github.com/bevyengine/bevy/blob/284889c64b2a4a4f67018e42a14062392edbd0aa/crates/bevy_render/src/camera/projection.rs#L80) property on [`OrthographicProjection`](https://docs.rs/bevy/0.4.0/bevy/render/camera/struct.OrthographicProjection.html) so you can zoom in using the camera. I believe that should solve both problems.

Yup. A workaround is to swap the two `#[cfg(feature = ...)]` attributes [here](https://github.com/dimforge/bevy_rapier/blob/e7aa26ad50e7471ce4119fb0ed42007787d1b5a7/src/render/lines/mod.rs#L34).

I had some trouble with refresh rates with a multi-monitor setup, so I switched to wayland and then bumped into this issue myself. I tried this PR, and while it...

@bjorn3 The rationale is explained in the linked issue.

I think this can be closed since #6126 landed.