Здравствуйте, PVitaliy, Вы писали:

PV>потом надо посчитать растояние каждой точки к центру
PV>[...]
PV>и выбрать минимальные.
Ну это практически эквивалентно тому, что каждый Path считается выпуклым многоугольником, и строго говоря, даже при таком предположении дает далеко не всегда верные результаты (точка (0,0) удалена от квадрата (1,100)(1,-100)(201,100)(201,-100) всего на одну единицу, хотя расстояние до ближайшей вершины больше ста)

Надо по-любому определить абстрактную функцию "расстояние от точки до GraphicsPath", и подобрать наиболее эффективную.
Алгоритм же не меняется — перебирать расстояния до всех и выдать минимум.
Здесь нужно не забыть, что расстояние может быть равно 0 (т.е. точка находится внутри Path). Тогда из всех Path, расстояние до которых 0, нужно вернуть Path с максимальным Z-Order-ом (или любую, если Z-Order пофиг).

Самая простая функция — это действительно считать расстояние до Path расстоянием до ближайшей точки Path. Но она может дать чудовищную погрешность. Когда Path имеет маленькую выпуклую форму, и их много, то это скорее лучшее решение. С этим подходом могут напортить кривые Безье — они могут очень сильно отклоняться от описывающего четырехугольника.

Чуть-чуть сложнее и точнее — это взять аппроксимацию Path многоугольником. Т.е. соединять все точки отрезками, и опускать перпендикуляры. Длину кратчайшего перпендикуляра, основание которого принадлежит отрезку, можно взять за искомое расстояние. Здесь, опять же, кривые Безье могут создать неприятную ситуацию.

Еще сложнее — анализировать, из чего состоит Path, и построить сложный геометрический алгоритм, с учетом ориентации, счетчиков выпуклости и пр. Очень нетривиальная задача, но если точность очень важна, то сделать реально.

Так что можно смело взять вариант PVitaliy и не мучаться