Difference(A, B) != Difference(A, Intersection(A, B))

[SleepProgger]

Logically, at least to my mind, Difference(A, B) should be equal to Difference(A, Intersection(A, B)), but that doesn't seem to be the case.
I am working only with integer paths.

So my question is a) is this a bug ?

and b) if not does someone have a hint how i could convert the result of Difference(A, Intersection(A, B)) to be the same, or at
least extremely similar to Difference(A, B) ?
The only way i found so far is to offset the result twice with a small value (first with negative, then with positive offset).
This leads to issues down the line though.

Sorry i can't share my test code at the moment as i am using the C++ Clipper bindings in another language.
But maybe these images will help demonstrating my issue:

The A and B polygons:

The result of Difference(A, B)

The result of Difference(A, Intersection(A, B))

The issue only occurs with non "straight" lines / polygons (In my test Offset(Vector2(510, 0), Vector2(500, 500), 20), 20) and offset(Vector2(0, 250), Vector2(1000, 250), 20)) so i assume the reason is internal rounding when finding the intersection points ?

[AngusJohnson]

A lot of effort has gone into returning solutions close to their simplest forms, but there's no way to do this perfectly without significantly degrading performance. So there will, on occasions, be solutions with polygons that are touching. If this is problematic, then a follow up union operation should bring these solutions much closer to their simplest forms.

See: https://www.angusj.com/clipper2/Docs/Overview.htm#closed_paths

[SleepProgger]

Thanks for the answer (and this awesome library).

My issue is that the image for "Difference(A, Intersection(A, B))" is one path (paths.size() == 1) and a follow up Union doesn't change anything.
Preserve collinear is disabled. (My bad should have mentioned that before).

This absolutely might be the "correct" behavior, even if logically i'd expect Difference(A, B) == Difference(A, Intersection(A, B)) to be the same.
Sadly i have no clue how i could even "split" it into two path (to be the same as in the simple Difference(A, B)), except offsetting the path slightly which besides the performance issue also leads to further problems in my case.
I'd be very grateful for any hints how i could go about fixing my issue.

[AngusJohnson]

Sadly i have no clue how i could even "split" it into two path

As above, have you tried unioning the result?

[SleepProgger]

Yes i did, all above images are after an additional union at the end

[SleepProgger]

So in conclusion am i right in assuming this isn't a "bug" and for what i need i'd need to roll my own post-processing step ?

(Maybe simply checking for each segments if it lies on another segment within some epsilon and if so split into two paths)

[AngusJohnson]

So in conclusion am i right in assuming this isn't a "bug" and for what i need i'd need to roll my own post-processing step ?

Yes 😁.