If the State and Country lists have been updated so the API values are set to ISO country codes the Masking of those fields during a data deployment does not work.
Data Load errors: '"FIELDINTEGRITYEXCEPTION:There's a problem with this country, even though it may appear correct. Please select a country/territory from the list of valid countries.: Billing Country:BillingCountry --"'

Disabling masking works around the issue.
It would be great if the application could check the State/Country list and utilize the API values for masking.

Currently you can only push to 1 Salesforce org, however, we manage multiple organizations and would like the capability to push the same package to multiple organizations

Currently its possible to replicate data from a backup job by going into the backup run and clicking replicate data.

However, this is extra steps... its would be good if you could just select backups as a source from the data deployment screen.

I would like to see a gearset defined template for Territory Management in Salesforce. I am definitely in need of this functionality as it seems to be a post deployment step once you deployed all Territory Management metadata.

in ETM 2.0 for example, after deploying the related metadata you need to deploy all related records for UserTerritory2Association Object, this contains who are the users assigned to a territory.

Not a big template but can be a good thing to have as a preset.

Stella PST password recovery software is the top programs that can retrieve all passwords of the pst file by using the most effective methods of password recovery methods. It recovers all passwords encrypted in the PST file. This software can recover all 64bit and 32bit pst passwords. Stella PST password recovery software will recover all key combination passwords for pst files.
For more information, visit this URL
https://www.stelladatarecovery.com/pst-password-recovery.html

It should be possible to have gearset to deactivate flows and/or processes based on a selection. And to roll-back afterwards. Similar to what has been created here: https://sfswitch.herokuapp.com/

When executing a data deployment, an 'Unable to lock row' error can occur if multiple transactions try to lock the same record in Salesforce.
Because the batches are executed parallel, the chances of getting this error high, depending on the situation.
For example the master record in a master:detail relationship will always get locked when a DML is executed on the child record.
If two batches are executed at the same time and they both have at least 1 record that references the same parent, then a locking error will occur.

When configuring a data deployment there is an option to disable validation rules and triggers on the target org. However the validation rules of objects of a managed package don't get included in this comparison. Triggers of a managed package are also not included.

I'm not sure if it will be possible to disable the triggers, but for validation rules this should be possible.

Currently gearset allows to deploy translations from one org to another org, however we do not have an option to do the translations using .stf file /excel for the fisrt time in any one of the org

I suggest you have functionality to show how big a data deployment is going to be when deploying, as some Salesforce sandboxes have a limit of 1GB

One great feature to have, would be the possibility to identify a Master object from which the filters applied on it would be applied on all dependent objects automatically.

Having the option to move up only selected fields in a Data deployment is needed. If we are required to move up all fields in each deployment, there are scenarios where our work will get bottlenecked in a sandbox on the way to production and at that point all the deployments will be identical.

Would love the ability to re-validate a deployment after making changes to the target org. I notice this a lot if there's a username issue that needs fixed in the target, I'm able to fix the issue without refreshing the comparison, but still have to return to the compare, go through the automated fixes, and then re-validate the deployment.

As a feature to enhance data deployments, make them invocable by Salesforce APEX (or other tooling) whenever a Sandbox is refreshed. Salesforce has a configuration to let the user specify an APEX trigger/class to run upon Sandbox creation. That could call the data deployments to run on the freshly minted sandbox, seeding it with data. This would enhance automation.

There are tools out there (like SFApex) that do something similar.