It would be incredibly helpful to trigger Gearset comparisons, validations, deployments, etc. from an external source using an API. Our team uses GitHub for our VCS, which provides the perfect opportunity to:
1. design webhooks to validate changes in order to approve a Pull Request
2. design webhooks to automatically deploy changes to an org once the PR is approved.

Additionally, CI tools such as Jenkins, TravisCI, TeamCity, etc could use such an API to design complex builds that still employ Gearset, but use the external tool for additional actions outside of what Gearset provides for their CI features.

Inline Editing of metadata
In order to make our deployment successful we had to download the package, modify the version numbers on the flow definitions, and then compare the local package to the target org. It would be very helpful if we can edit the metadata XML in the UI so we can fix the version numbers.

It would be great to refresh a specific item within a comparison that I know has changed since the last comparison.

Extend the diff tool to allow the user to perform a merge, creating a new version of the component that contains some changes from the source version and some changes from the target version. This would be very useful in a team development scenario where multiple devs are working on features in individual dev sandboxes and then pushing completed features into an integration sandbox.

It would be great to have more control over the diff process - particularly to be able to ignore whitespace changes.

If I've made an actual function change to a class, and also auto-indented it, then it would be a lot easier to see the important change if I could hide the whitespace-only changes.

Having the ability to suppress whitespace-only changes on the list of changed objects would be really useful, too.

As Gearset is run through a web browser, if the browser happens to freeze while a package is being built, you don't have the opportunity to save it as a Draft Deployment. An auto-save feature would allow someone to pick up where they left off, or when the last auto-save was done, without having to start from scratch.

create an option to have chained deployments so complex deployments can be broken down and sequentially deployed or slaves can be ran

allowing for multi staged deployments under one CI job

Allow individual lines to be selected for inclusion or exclusion of a deployment

When using a git repo with a SFDX folder structure + package/xml (in the /manifest folder) gearset dos not take into account elements in the package.xml when checking the option (filter with package.xml)

Manual deployments and change monitoring jobs can be rolled back. Add the same function to CI jobs in case it accidentally deploys something unwanted

It would be nice to be able to deploy to multiple environments all at once from one source.

In most of Tech industry deployment lifecycle, all code or config changes are ideally pushed into production only from a FullCopy Sandbox(Commonly Known as Staging Environment).

It would be very good to have a feature in GearSet App which if enabled shouldn't allow user deploying data from Dev/DevPro/Partial Sandbox into Production Org.

Allow user to directly create a change set without doing the comparison. If user has a list of items that needs to be migrated then allow the user to add items and skip comparison step.

At commit to branch, Gearset reorders large chunks of the XML file. This causes additional deltas (seen in the hundreds of lines) and merge conflicts.

Allow assets with "no difference" to be added to a promotion to allow the same package to be used to both promote as well as sync other sandboxes (without having to manually check if asset was changed in each).

It would be great to be able to copy Territory models from one org to another, as per this request in the SFDC Community...
https://success.salesforce.com/ideaView?id=08730000000DgemAAC

Allow gearset CI to do a quick deploy either by default or via a setting on the Job definition.
Our tests run for nearly 90 minutes and are currently run twice in succession causing a lot of frustration. Once when a PR is validated and then when it is merged and deployed.

I would like to inform Slack on when a manual deployment is successful or failed. It will tell me what the source environment and what was the destination environment. It will also tell me if what the success/fail ratio of the tests that were run.