notably this is often required when doing work with early release-candidates, or crates that haven't published their transitive dependencies to crates.io, etc.

One question is if you run bevy patch A followed by bevy patch B, will A be removed from Cargo.toml and replaced with B? If so, the command needs to be able to detect existing bevy subcrate patches. What if the user has e.g. a single manually-written patch like bevy_ecs = { ... }, will bevy patch overwrite that? If not, it would have to be able to distinguish between bevy patch patches and user-written patches, which seems impossible.

Maybe it can comment out previous patches instead of overwriting? But anyways, everyone uses version control so overwriting is probably fine.

I don't necessarily think it needs to modify Cargo.toml, especially in its first form. It just needs to dump the generated list to console. The full list is awkward to access and write out otherwise. Even dumping bevy = { git="<git>", branch = "<branch>" } for the crate list would be useful (which could then be multi-cursor modified by a user pasting it into their Cargo.toml).

Good point. Even in the final form, it could dump the text by default and include a -w, --write flag to actually write the patch.

also slight preference for something like bevy patch --list existing anyway, even if modification is implemented

You can pretty easily find a list of all 1st-party Bevy crates in a workspace by running:

cargo metadata --format-version 1 | jq '.packages[] | select(.name == "bevy_internal") | .dependencies[] | .name'

nice. cooked up a nushell version based on that (mostly for myself soon when 0.15 drops)

cargo metadata --format-version 1 | from json | get packages | where name == bevy_internal | first | get dependencies.name | each {|it| $'($it) = { git = "<git>", rev = "<rev>" }' } | str join "\n"

bevy_a11y = { git = "<git>", rev = "<rev>" }
bevy_animation = { git = "<git>", rev = "<rev>" }
bevy_app = { git = "<git>", rev = "<rev>" }
...

Note that the above two commands do not include bevy_dylib since bevy, but not bevy_internal, depends on it directly.