As I have the impression you are talking not about needing to have the jobs constantly take turns running, but about needing neither one to run while the other one is (independently of what triggers them), I will point out that you can set conditions (including that another job is running) at the job level, not just at the task level. I actually have a case I ought to have set up exactly as I think you're describing, but I just realized I've been getting away with having it in only one direction because their schedules and run durations are such that the one without a condition is very unlikely to attempt to run while the other one is in progress.
Also, you can have multiple conditions in a condition set and multiple conditions for a given job or task, which can get pretty complicated; however, conditions and condition sets' existence is at the server level, which can also get confusing - I have condition sets I really need to rename because their existence doesn't make sense unless you look at the job they were originally created for.
It sounds to me as if you might actually be talking about the Flow tab rather than Conditions; Flow tends to be simpler and easier (in my opinion), right up to the point where you need something more complex than Flow can easily handle.
Still, if the condition sets being global is a problem for your use case, you could theoretically have each job start with a task that does nothing of consequence, and give that task an "on complete" flow for "If Other Value" "{JOB(<the other job's id>|Status)}" "Equal" "Running" "Stop Job" as a possible example. I don't really recommend it, though, because it's not an obvious workaround.
...And, all that long-winded stuff being said, if what you actually want is to kick off one of the two jobs and have them both alternate running constantly until one of them fails, but neither one be kicked off any other way, then by all means, the trigger approach should do that just fine.