Fragmentation with PXC setup using an ordered UUID as PK
Good.  You understand the problem inherit in UUIDs, and understand how to "fix" it.

Let's start from the other end...  Since you are keeping the data for 2 years, let's start with partitioning by date.  I don't care whether the data is INT, TIMESTAMP, DATETIME, BIGINT, or a rearranged V1 UUID.  (However, you should probably use an date that matches your application.)

PARTITION by the date into 24 partitions.  Each month, DROP the oldest partition and REORGANIZE the future partition into future and nextmonth.  See my blog for more details.

OK, that solves the problem you have not yet encountered -- the ugly overhead of deleting a million rows a month.

But, your concern was about ordering of the clock.  It is not really a problem.  And it is not worth chasing.  Even if an INSERT is a second late -- or even an hour late -- it will make very little difference in the overall performance of the inserts.

Sure, the 'next' row onto the 'end' of a table is well optimized.  But inserting it somewhere in the 'last' block, or even last 100 blocks, is efficient enough.  At best, InnoDB keeps blocks not quite full.  At steadystate with a lot of churn, a BTree is 69% full.  For "Point queries" this number is mostly irrelevant.  For range scans, it has some impact.  I suggest that preventing fragmentation is more costly than ignoring it.

Even with just AUTO_INCREMENT, you cannot be assured that rows will be inserted visible in order!  Think about what happens with multiple threads doing:

BEGIN;
INSERT ... -- the next AUTO_INCREMENT value is grabbed now
...        -- take a variable amount of time
COMMIT;    -- only now is the AI visible to the rest of the world.


So, give up on strict ordering.