I think some people or confusing this idea with having chained CI jobs. I believe that is two different ideas; this one being chaining standard Compare & Deploy deployments vs. chaining CI jobs. Although I have not attempted it, I believe you could set up an outgoing webhook from one CI job and use that as the incoming webhook in the other.

I would like to be able to specify which hour a given job would start.

That will be really handy. Once I have pushed changes to a branch using gearset, IF gearset can have a script to fire the jobs in sequence to push them to branches and orgs in sequence until it reaches Production that will remove a lot of manual effort. In fact that will be a USP for gearset if no other automated ci-cd solution haven't achieved that yet.

That would be such a great thing! It would enhance even more gearset's current features and make our lives so much easier.
Many CI errors will be avoided and lots of manual time spent on some minor metadata issues, if we could just chain the jobs

If this idea is implemented then it would be a lot of time saver. The manual deployments to different sandbox would be redundant to fix the CI issue

Great idea. We have been turning metadata types on and off to fix these dependency issues, which is taking a tremendous amount of our time for each sandbox running with CI. A feature like this where we can chain CI jobs, e.g. job 2 won't start until job 1 is complete would be such as life saver.

For our CI flow, when a feature branch is merged into our source control branch we would like to:
1. Deploy changes to a deployment validation sandbox
2. If that was succesful, deploy the changes to a system test sandbox

This would be very helpful in satisfying this use-case

This is a GREAT idea!

That would be such a great idea

for us, this would be:

source -> CI -> PASSES? -> then clone and source -> QA org