I'm not actually sure how this issue relates to your issue, but I think that even if it is a different problem, we can have the same solution with a new object.
This works, but it currently requires an external, both in vanilla and my usage of libpd in PdParty.
Anyway, on to your message: what external are you using?
The only thing that might break would be using one of these objects within an abstraction and *expecting* the path to be relative to the abstraction, not any parent. In this case, I introduce the explicit ./ or ../ check which forces the paths to be treated as relative to the abstraction.
This also implicitly removes the *urgent* need for a suite of fuel path objects, at least for me. :)
Maybe we don't need a whole suit of functionalities into a new object all at once. Perhaps a solution could start with a simple object that takes care of the most urgent stuff. I think I have the same kind of issue and what I'm doing is using an external like [getdir]. The functionalties from [getdir] seem very important and should be available in Vanilla not only for this, but also for something like dynamic patching, where we want to send pd an "open" message and it requires the path as a second argument.
So then a new object that starts with only this could be good solution to your urgency, and it wouldn't break anything in any context, and it is something that will eventually need to happen as I see it.
Cheers