So you want to purge the previous Incrementals at the START of the new day, not after you've accumulated a new day's worth of Incrementals?  I'm not sure there's a way to achieve that.  The closest you could probably come would be to set your Incremental retention policy to 1 Day, but I think that would mean you'd end up with a full day's of Incrementals and still have the previous day's Incrementals, i.e. any Incremental created on the previous day, regardless of time of day, would still be retained under this setup.  The other option would be to set your Incremental retention policy to the number of Incrementals you generate in a typical day, in which case the previous day's Incrementals would be purged throughout the day as you created new ones.  But I don't think there's a way to have configure Reflect such that it will purge all existing Incrementals at the start of a new day, then allow a new batch to accumulate before purging all of those at the beginning of the following day -- because there's no way to set a retention policy of 0 days or 0 Incremental backups.

Well no sooner had I wrote that than I thought of a way to do this, if you're really willing to accept the additional complexity.

It would involve two separate definition files -- not just separate schedules in a single definition file.  The first one that you're using now would carry on as-is (or nearly as-is).  The second definition file would be created by duplicating your existing definition file (right-click it and select Duplicate), then you would configure its retention policy to have the Full and Diff policies disabled and the Incremental retention policy set to 1 Incremental backup.  You would then configure a schedule for this definition file to create an Incremental backup each day, at a time that would make it the FIRST Incremental to be created each day.  And finally, you would enable the "Run purge before backup" option.

The end result will be that each day, this secondary definition file would create one Incremental, and the combination of the "1 Incremental backup" policy and the "Run purge before backup" option being enabled means that all previous Incrementals will be purged before the new one is even created.  And then for the rest of the day, your "regular" definition file will create all other Incrementals, as well as the Fulls and Differentials you want.  In terms of possibly required changes to that "regular" definition file, you'd of course want to make sure its first scheduled Incremental each day was later than the one created by the secondary definition file.  You should also disable the Incremental retention policy on that definition file, since Incremental purges will now be handled by your secondary definition file.

As long as the definition files are otherwise identical in terms of data being backed up and the destination of the backups -- which they will be if you duplicate the existing definition file -- then your backup sets will still operate normally.  It won't matter that different backups in your set were created by different definition files.  But if you do make changes later on, you'll want to make sure to update both definition files to keep them in sync apart from the areas where you have deliberately different configurations.