My file and folder backup regime is set to retain 30 incremental backups and create a synthetic full. All works fine.
If I decide to run another full backup is there a way of forcing MR to create subsequent incremental backups on top of the new full backup rather than from the original full backup?
The reason for this is that the consolidation\merge process can take some time so it'd be great if I could decide when to run another full backup knowing  that this would be used for the next incrementals.

When you create a new Incremental, Reflect always appends it to the most recent eligible backup.  So if you create a new Full, then subsequent Incrementals will automatically be created as children of that Full, and in fact you wouldn't be able to have Reflect do anything else.  However, that won't solve the issue you're trying to solve, because you can still have consolidation occur within the previous set.  That's because if you set an Incremental retention of 30 backups, that is not 30 Incremental backups per Full.  It is 30 total Incrementals across all matching backups.  So let's say you start with an empty folder.  You create a Full and then 29 Incrementals, and then another Full.  The next Incremental will become the first Incremental of the new Full.  At that point you have 30 Incremental backups total.  And therefore when you create your NEXT Incremental, it too will be a child of the latest Full, but the consolidation will occur between the previous Full and its oldest Incremental (since you're using Synthetic Fulls).  That way you'll be back down to 30 total Incrementals, which at that point will be 28 Incrementals on the old Full and 2 Incrementals on the new one.  This process will continue going forward, with new Incrementals being added to the latest Full but the consolidation occurring between the previous Full and its oldest Incremental, until the previous Full no longer has any Incrementals at all.

Many thanks for that great reply. That makes perfect sense.
The reason for my confusion was seeing MR process the old backup chain when consolidating which gave the impression that it was only processing\backing up using the old chain when this wasn't the case.

Happy to help!   Yes, this can create some confusion, especially for users who view their backups in Windows Explorer and sort by Date Modified.  In that case, if you have "Run purge before backup" disabled so that consolidation occurs at the end, the oldest Full will end up with the most recent Date Modified timestamp.  This causes some users to think that they're getting new backups in an old set, but with backups strategies that involve consolidations, the Date Modified timestamp is not necessarily correlated to the "backup date", i.e. the time of the data actually contained within the backup.