When navigating to the 'Metadata filter' tab to select filters, there are currently 122 options, however 'List View' is not one of them.
When navigating 'Metadata Types & Components' in Workbench, 'ListView' is described independently, and I have used it previously when deploying via ANT. Therefore I would imagine there is a way to identify List Views independently of 'Custom Objects'.
This would be a huge help with a Production monitoring job, as I do not mind if List Views are updated by certain users in Production, but currently they are flagged as differences. Basically, I want to ignore them in my monitoring job.

It can be difficult to evaluate the scope of changes by clicking in the Comparison view on one metadata element at a time to see the differences. We would much prefer to be able to download a git diff and examine the delta as a cohesive changeset.

The user should be able to download the contents of the currently selected tab (All Changes, New Changes, or Selected Changes) in the format of a git unified diff. The user can then use the software of their choice to view the diff.

This will also enable more advanced workflows, as git diffs can be applied as both forward and reverse patches, to test or rollback changes to a git branch. This will also help detect the chance of merge conflicts and to see where unintended changes are added to a deployment (e.g., Profile alterations due to incomplete metadata or filtered out objects).

The problem analysis comes up with a number of Suggested Fixes which may make sense for improving Salesforce deployments, but which are unproductive when applied to git deployments.

For example, the suggestion to remove TASK.WHAT_NAME, or to omit Standard Objects, will only serve to create a git repo which is an inaccurate reflection of the source org. Each time we deploy to that git repo, we will continue to have the same changes to select or omit, since the repo is missing objects and fields from the source org.

When the deployment target is a git repo, all suggested fixes which remove fields and metadata in accordance with Salesforce best practices should be hidden/suppressed/omitted. Suggested fixes which add necessary dependencies to the deployment should still be displayed.

Gearset provides some very useful documentation on the importance of including groups of related metadata in a filter.

https://docs.gearset.com/metadata-deployment-guides/using-gearset-to-deploy-profiles

It would be very helpful if the Manage Filters dialog implemented these suggestions. For example, when a Profile is included in the filter, the user should be prompted to also select Profile Password Policy, Profile Session Setting, External Data Source, Apex pages, Layouts, and Custom Objects. Otherwise, the likelihood of Gearset assembling an accurate Profile without all of the related components will be slim.

Gearset obviously has deep knowledge of metadata semantics and dependencies. The Manage Filter page needs to reflect these smarts, or else it becomes too easy to create failed deployments.

Currently, when gearset deploys XML to git, it seems to run it through a reformatter, which creates superfluous changes in git. These changes cause extremely large deltas, which are hard to read, increase the difficulty of merges and the likelihood of conflicts, and make working with any other metadata tooling (like SFDX) difficult.

For example, here is part of a delta gearset commited for a profile.xml:
diff --git a/force-app/main/default/profiles/Commissions.profile-meta.xml b/force-app/main/default/profiles/Commissions.profile-meta.xml
index 8b11e6b7..3d640a50 100644
--- a/force-app/main/default/profiles/Commissions.profile-meta.xml
+++ b/force-app/main/default/profiles/Commissions.profile-meta.xml
@@ -1,10 +1,27 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<Profile xmlns="http://soap.sforce.com/2006/04/metadata">
+<?xml version="1.0" encoding="utf-8"?><Profile xmlns="http://soap.sforce.com/2006/04/metadata">
+ <custom>true</custom>
+ <profileActionOverrides>
+ <actionName>Tab</actionName>

Note that it lowercased the "UTF-8" encoding and removed the newline after the xml prolog.

At the moment, you can select "Installed package" as a metadata type to compare, and I think you can use this to install a package (without installation key).

However, unless I'm missing them, 2nd Generation Unlocked packages don't appear in a comparison like this.

It would be really useful to be able to deploy 2GP with Gearset because I sometimes need to make metadata changes at the same time as installing

e.g. I'm moving some old functionality into an Unlocked package and that old code has logic in the triggers. I want to be able to delete the old triggers at the same time as installing an Unlocked package that implements the logic via a trigger framework. Right now, I'm working around it by including an empty trigger with the same name in my 2GP. That wipes out the old one on the first install, then I need to do another package version to remove the empty trigger.

On metadata deployments, I frequently struggle with Report Folders, Workflow Updates, and other configuration elements that have individual users assigned to them. The struggle is that individual users assigned to these config elements often do not exist in the target org. This results in the entire deployment failing, and many times, manually configuring the report, report folder, etc.

A nice solution to this would be a new section on the Problem analysis screen that allows me to exclude the users from the config element that is being deployed.

It is useful to call these scenarios out, because I need to remind developers and admins that the proper way to set these up is to add a group to the folder, workflow rule, etc, then the people to the group. This is the only method that I have found to prevent these configuration elements from failing my deployments.