Ok, this post is going to be a mixture of clarifications in terms of how Reflect and synthetic fulls work, and also some of my own best practice recommendations.

First, the only time Reflect ever generates a synthetic full is when it creates a new Incremental and the resulting number of Incrementals in the chain exceeds the number you've specified in your retention period.  For example, in my "Incrementals Forever with Synthetic Fulls" job, I specify to retain 7 Incrementals.  The first time my job executed, it generated a Full.  Then each of the next 7 times, Incrementals were generated.  The time after that, an 8th Incremental was generated, but since that exceeds my retention policy, at that point Reflect automatically merged Incremental #1 into my Full backup, thereby "carrying the Full forward" so that I have a Full equivalent to having actually captured a Full on the day Incremental #1 ran, even though I didn't actually run a Full that day -- hence the name "synthetic full".  Incremental #1 is deleted after the Full is updated with its contents (thereby keeping my backup set compliant with my retention policy), and of course I lose the ability to restore all the way back to the day I ACTUALLY ran that Full.  From that point on, this process of merging the oldest Incremental into the root Full continues each time a new Incremental is generated, thereby keeping your backup set current without the number of Incrementals ever exceeding the retention policy you specify.  But if you set a retention policy of 30 Incrementals, you won't ever get a synthetic full until Incremental #31 is being created.  The strategy you're describing above sounds like you'd only ever have a Full followed by 30 Incrementals, and then you'd manually capture a new Full -- nothing at all wrong with that strategy, but you'd never get a Synthetic Full out of that.

Now, a few best practice recommendations.  If you've got 2 targets, I would recommend that you instead rotate them back and forth on a weekly basis rather than keeping both connected all the time and backing up to one of them for 2 months before switching to the other.  Weekly rotations will allow you to keep some of your backups offline (safe from ransomware), which additionally gives you the option to store them off-site for protection against break-ins, natural disasters, etc.  And by rotating them weekly, you'll ensure that even if you do lose the drive with the most recent backup, the "fallback" drive is no more than a week out of date rather than 2 months.  Finally, you wouldn't even need 2 separate schedules.  If only one drive is ever connected at a time and it's assigned a consistent drive letter (there are tools to enforce this), you could just set up a single schedule and Reflect will simply back up to whichever set is available at the time a backup runs.  Backup sets on different disks are wholly independent from each other (i.e. you would never have a situation where an Incremental chain requires files from two different disks).  Alternatively, you can use Reflect's built-in support for specifying additional destinations and targeting them by Disk ID rather than drive letter, in which case Reflect will again use whichever drive is available at any given time when the backup runs, or the first available drive in the list if multiple targets are available, all regardless of drive letter assignment.  Easier scheduling and better resilience -- what's not to love?

However, if you do want to temporarily pause a scheduled task, you can do so under the Scheduled Tasks tab by right-clicking it and choosing "Disable" -- although this will disable ALL scheduled backup types for that definition file.  If you want to stop all scheduled jobs for a task permanently, you'd just go to Edit Schedule and remove all scheduled backup types.  The definition file would still stay there in case you wanted to run it manually.

Yes, you can delete older backup sets if you want, but the idea of "Incrementals Forever with Synthetic Fulls" is that you don't ever have more than one set on a given disk.  Instead, you just decide how far back you'd ever need to restore, and set your retention period as appropriate to achieve that based on the frequency of backups.  For example, if you wanted 2 months of history on each of your 2 disks and you were rotating them weekly with backups running every day, you'd just set your retention policy to 27.  The Full plus those 27 Incrementals is 28 backups, or 4 weeks' worth -- but since each disk is only being used every other week, that allows you to go 8 weeks back in time, with each disk having alternate weeks' backups on it.   Does that make sense?