Deleting Incrementals as a group is certainly doable, but you don't HAVE to do it that way in Reflect if you don't want to. The virtue of consolidation is that you don't have days where you only get one new backup (a Full) but lose an entire week's worth of backups, for example. You can instead follow a "one in, one out" idea. So for example you could have a plan whereby you capture one Full each week and an Incremental every day, and you always retain the last 2 weeks' worth of daily Incrementals, but you want the last 5 weeks' worth of weekly Fulls. So after you had 2 weeks' worth of backups, as you worked through Week 3, each time you created a new Incremental, the oldest remaining Week 1 Incremental would be purged. So in this setup, you would purge child Incrementals of a given Full BEFORE you purged the parent Full itself. The idea here would be that for recent history, you might want to have daily backups available to restore from, but if you need to reach back farther in time, you might be fine only having weekly backups to choose from. Reflect lets you configure retention policies that would achieve that. You don't necessarily have to delete backups in the same order that you created them. Macrium has a nice animation of this Incremental Merge concept here
. There's a variation of this called Synthetic Fulls where the Full itself gets "carried forward" in time as well rather than the oldest two Incrementals always being consolidated. That avoids the widening "time gap" that is otherwise created between the Full and the oldest remaining Incremental. But if you're creating Fulls on a fairly regular basis, Synthetic Fulls might not be worthwhile.
But if you would prefer to stick with purging an entire set at a time as you've been doing, then yes you would create multiple schedules associated with a single definition file. I've provided a screenshot below of the schedule and retention policy that would achieve what you described in your first post. Note that since the Full and Incremental schedules are set for the same time of day, on days when both a Full and Incremental would be scheduled, Reflect will automatically ignore the Incremental and only perform the Full, which makes it a bit easier to specify schedules like this without having to manually create exceptions for "Full days".
In terms of how Incrementals get tied to a Full, whenever creating an Incremental (or Differential, for that matter) Reflect always "appends" to the most recent "eligible" backup at the destination. So if you request an Incremental, it will be appended to the most recent "matching" backup at the destination, regardless of type (Full, Diff, Inc), since Incrementals can be appended to existing Fulls, Diffs, or Incs. If you were to request a Diff, it would be appended to the most recent "matching" FULL at the destination. In terms of what constitutes a "matching" backup, when performing image backups, an existing backup would only be considered a match for the new backup being created if the existing backup contains EXACTLY the same partitions as the ones being backed up in the new job. That means no additional or omitted partitions, the same partition sizes, and the same partition "offsets" (position on disk). So for example it wouldn't be possible to create an Incremental as a child of a completely unrelated Full backup even if you were sending backups from multiple unrelated jobs all to the same destination folder. But by the same token, if you ever adjust your partition map by shrinking or extending a partition, that will cause future backups created by the SAME job not to be a "match" for your existing backups. At that point, you'll need to create a new Full. If your schedule specifies an Incremental and Reflect can't find any "matching" backups at the destination to append to, then it will automatically create a Full and note this deviation and the reason for it in the job log. Sometimes upgrading to a new release of Windows 10 can cause changes to your partition map, so this can happen unexpectedly. In addition, by default the retention policy is set to act only on MATCHING backups. This is a safeguard for cases where multiple unrelated backups are stored in the same folder. But that means that if your new backups no longer match the old ones, then your retention policy will no longer act on those older backups. That can be addressed by setting your retention policy to act on all backups in the destination, but if you do that, make sure your destination folder stores ONLY backups created by a specific job, otherwise Job A could purge completely unrelated backups created by Job B. More info about this Windows 10 upgrade issue here
But here is a screenshot of an example job schedule and retention policy that would achieve what you described in your first post: