I think this is more of a convention issue than a bug.

The convention for putting the impact point on the target object makes some sense from the perspective of a sweep because this method is written to sweep the sweep object against the target object and find the distance to move and impact point that it hits the target object at. If the shapes were initially disjoint, the impact point on either shape should coincide and it doesn’t matter which shape got inflated. In fact, in the implementation, neither shape gets inflated - it’s the Minkowski sum of the 2 shapes that’s inflated.

If you know that the impact point will always be on the surface of the inflated target object (not the sweep object), then you can use the normal, distance values and inflation amount to compute the equivalent point on the other shape if that’s what you want.

For example, if you would like to get the impact point on the surface of the uninflated shape B (the closest point), it should be possible to compute that from the information provided like this:

closestPointOnTarget = impactPointOnInflatedTarget - normal*(inflation)

If you want the closest point on the sweep shape, you can compute that from the closestPointOnTarget as below:

closestPointOnSweep = closestPointOnTarget + normal * distance

If you want the point on the surface of inflated A, which is what I think you expected from this function, you could also compute that. That’s likely to be something like this:

impactPointOnInflatedSweepObject = impactPointOnInflatedTarget + normal*(distance-inflation)

Please note that I didn’t try this and there’s a pretty good chance that the convention for the direction of the normal means that cases of “- normal * x” may need to be interchanged with “+ normal * x” and vice-versa to get the desired results. However, there should be enough information returned by this method for you to get the information you require without using your root-finding approach.