Jasper Mayone's RFC teaches git worktree list the --merged and --no-merged filters that git branch, git tag and git for-each-ref already have, applied to the HEAD of each worktree. He keeps one worktree per topic, and since the branch stays checked out there after a topic lands, git branch --delete-merged skips it. The command only lists; removal stays a separate step.
The thread also carries messages from a related series by Mayone. In the excerpts, patch 1 makes git worktree remove refuse a worktree in the middle of a rebase, am, bisect, cherry-pick or revert unless --force is given, even when its files are clean. Patch 2 documents how to read %(worktreepath) safely. Patch 3 makes %(worktreepath) name the worktree that is rebasing or bisecting a branch. Patch 4 keeps git branch from marking such a branch with "+" in that worktree itself.
Phillip Wood reviewed the series. He pointed out that a single cherry-pick or revert with no new changes also looks clean but leaves CHERRY_PICK_HEAD or REVERT_HEAD, so those should be checked too. He also suggested a list of conditions that require --force, and wording fixes such as "refuses to move".
Mayone agreed to all of this for v4. The new version will check for CHERRY_PICK_HEAD and REVERT_HEAD, and the remove description will become a list of what makes a worktree unclean. He also added a branch_checked_out_worktree() function in branch.c that reads the list built by prepare_checked_out_branches(), letting ref-filter drop its own hashmap. He reports that t6302, t3203, t3200, t2400 and t2403 pass with it.
The RFC itself has not yet drawn extended design comment in these excerpts.