This got me going properly, it did!

I have an accepted submission now, but it doesn't always pass the random tests; e.g. when the E shape intersects in a way that one of its original points is not inside the other shape, but is entirely inside the merged shape:

In that case my solution can end up producing a smaller inner shape, because it selected one of the points on the E or the other shape that's part of that inner smaller region:

Perhaps that should be added to the fixed tests?

I wonder if using floats as inputs and outputs does not make things unnecessarily complicated, because now you have to add tolerance to all kinds of checks like equality of points, collinearity, etc., and document it. However, this kind of linear calculations can be done completely in rational numbers (i.e. fractions). If you made input points always placed on integer lattice, or possibly in locations with fractional coordinates, then all intersection points could be represented with fractions, and compared for strict equality. There would be no need for tolerance checks, there would be no potential ambiguities like should the points common for input and output be returned identical, or will they be also compared with tolerance, etc.