Thanks to Sam we narrowed it down to PhysicalUnion::BuildPipelines, if we set order_matters to true this test failure disappears.

@Mytherin I'm not exactly sure what the right course of action here is
Are we fine skipping this test when FORCE_ASYNC_SINK_SOURCE is set (accept that this is expected behavior), or should we look into it more deeply and fix it somehow?

Skipping the test seems fine to me - although I wonder if we want to test this behavior in the first place? Do we want to make an effort to ensure this guarantee holds up (if INSERT OR REPLACE contains duplicates we're guaranteed to have only the last duplicate in the table)?

I don't feel strongly about it either way

if INSERT OR REPLACE contains duplicates we're guaranteed to have only the last duplicate in the table

When executed in parallel this falls apart, but otherwise I think we can guarantee it?
But I don't know whether this is important to guarantee

Thanks!